Subject: [sipcore] Precondition and status confirmation in regular two party calls

From: Ivo Sedlacek <[email-masked]>
Date: Wed, 28 May 2014 11:55:48 +0000

Hello,

can you please help me with a one more question related to precondition handling in RFC3312?

RFC3312 describes usage of confirm-status attribute - in summary, if a UA receives the confirm-status attribute, the UA shall send UPDATE once the UA finishes resource reservation.

However, RFC3312 does not explicitly state anything about sending UPDATE if the confirm-status attribute has NOT been received. If the UA does *NOT* receive confirm-status attribute, and if the UA sent the UPDATE request once the UA finishes resource reservation, it may cause unnecessary race conditions since both UAs can send UPDATEs at about the same time.

Question:
-----------
I assume that if a UA does *NOT* receive confirm-status attribute, then when the UA finishes the resource reservation, the UA SHOULD NOT send UPDATE request. Is this correct understanding?
-----------

Thanks for clarification.

Kind regards

Ivo Sedlacek

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 28 May 2014 14:31:52 -0400

> From: Ivo Sedlacek <[email-masked]>

> However, RFC3312 does not explicitly state anything about sending
> UPDATE if the confirm-status attribute has NOT been received. If the
> UA does *NOT* receive confirm-status attribute, and if the UA sent
> the UPDATE request once the UA finishes resource reservation, it may
> cause unnecessary race conditions since both UAs can send UPDATEs at
> about the same time.

The handling of race conditions regarding UPDATE is described in RFC
3331 section 5.2:

   A UAS that receives an UPDATE before it has generated a final
   response to a previous UPDATE on the same dialog MUST return a 500
   response to the new UPDATE, and MUST include a Retry-After header
   field with a randomly chosen value between 0 and 10 seconds.

   If an UPDATE is received that contains an offer, and the UAS has
   generated an offer (in an UPDATE, PRACK or INVITE) to which it has
   not yet received an answer, the UAS MUST reject the UPDATE with a 491
   response.  Similarly, if an UPDATE is received that contains an
   offer, and the UAS has received an offer (in an UPDATE, PRACK, or
   INVITE) to which it has not yet generated an answer, the UAS MUST
   reject the UPDATE with a 500 response, and MUST include a Retry-After
   header field with a randomly chosen value between 0 and 10 seconds.
   [...]

> Question:
> -----------
> I assume that if a UA does *NOT* receive confirm-status attribute,
> then when the UA finishes the resource reservation, the UA SHOULD
> NOT send UPDATE request. Is this correct understanding?
> -----------

In principle, a UA can send an UPDATE at any time when it is not
forbidden to.  RFC 3311 section 5.1 gives some guidelines:

   The UPDATE request is constructed as would any other request within
   an existing dialog, as described in Section 12.2.1 of RFC 3261.  It
   MAY be sent for both early and confirmed dialogs, and MAY be sent by
   either caller or callee.  Although UPDATE can be used on confirmed
   dialogs, it is RECOMMENDED that a re-INVITE be used instead.  This is
   because an UPDATE needs to be answered immediately, ruling out the
   possibility of user approval.  Such approval will frequently be
   needed, and is possible with a re-INVITE.

Dale

---

From: Ivo Sedlacek <[email-masked]>
Date: Thu, 29 May 2014 14:33:22 +0000

Hello,

The issue is not the race condition as such.  As you say, UPDATE is allowed to be sent at any time and there are procedures to handle UPDATEs being sent by both UAs at about the same time.

The question was rather: Is it advisable for a UA to send an UPDATE indicating that its resources are available if confirm-status attribute was *NOT* received?

Sending such non-requested UPDATE can generate unnecessary signalling (if both UAs reserve resources at about the same time, both UAs send UPDATE at about the same time and 491 would be generated) and call setup delay (since at last one of the UPDATEs will need to be repeated).

The whole reason for the confirm-status attribute is to request a confirmation when resources becomes available. So if the confirm-status attribute is *NOT* present, when resources becomes available, a UA should refrain from sending UPDATE (unless there is another reason, not related to resource reservation, for doing so).

Do you agree?

Kind regards

Ivo Sedlacek

This Communication is Confidential. We only send and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer 

-----Original Message-----
From: Dale R. Worley [mailto:[email-masked]] 
Sent: 28. května 2014 20:32
To: Ivo Sedlacek
Cc: [email-masked]
Subject: Re: [sipcore] Precondition and status confirmation in regular two party calls

> UA does *NOT* receive confirm-status attribute, and if the UA sent the 
> UPDATE request once the UA finishes resource reservation, it may cause 
> unnecessary race conditions since both UAs can send UPDATEs at about 
> the same time.

> then when the UA finishes the resource reservation, the UA SHOULD NOT 
> send UPDATE request. Is this correct understanding?
> -----------

In principle, a UA can send an UPDATE at any time when it is not forbidden to.  RFC 3311 section 5.1 gives some guidelines:

Dale

---

From: Ivo Sedlacek <[email-masked]>
Date: Thu, 29 May 2014 14:58:53 +0000

(minor reformulation below, sorry about being sloppy).

Hello,

The whole reason for the confirm-status attribute is to request a confirmation when resources becomes available. So if UA has *NOT* received the confirm-status attribute, then when resources of the UA becomes available, the UA should refrain from sending UPDATE (unless there is another reason, not related to resource reservation, for doing so).

Do you agree?

Kind regards

Ivo Sedlacek

-----Original Message-----
From: Dale R. Worley [mailto:[email-masked]]
Sent: 28. května 2014 20:32
To: Ivo Sedlacek
Cc: [email-masked]
Subject: Re: [sipcore] Precondition and status confirmation in regular two party calls

Dale

_______________________________________________
sipcore mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sipcore

---

From: [email-masked] (Dale R. Worley)
Date: Fri, 30 May 2014 15:14:34 -0400

> The whole reason for the confirm-status attribute is to request a
> confirmation when resources becomes available. So if UA has *NOT*
> received the confirm-status attribute, then when resources of the UA
> becomes available, the UA should refrain from sending UPDATE (unless
> there is another reason, not related to resource reservation, for
> doing so).
> 
> Do you agree?

Yes.  It seems to be a case of "Do not send UPDATE unless there is a
reason to."

Dale

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Sat, 31 May 2014 14:20:11 +0000

I Agree as well

Martin Dolly
Lead Member of Technical Staff
Core Network & Gov't/Regulatory Standards  
AT&T Standards and Industry Alliances
+1-609-903-3360
[email-masked]