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

From: <[email-masked]>
Date: Wed, 4 Jun 2014 10:29:28 +0200

Hi,
I also agree on that.
Do we need any documentation on that issue to help implementers on that?

Best Regards

Roland

-----Ursprüngliche Nachricht-----
Von: sipcore [mailto:[email-masked]] Im Auftrag von Dale R. Worley
Gesendet: Freitag, 30. Mai 2014 21:15
An: [email-masked]
Betreff: Re: [sipcore] Precondition and status confirmation in regular two party calls

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

> 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

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

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 04 Jun 2014 13:45:04 -0400

> Do we need any documentation on that issue to help implementers on that?

This seems to simply be a quality of implementation issue and common 
sense rather than a specification issue. I don't see this as 
fundamentally different from the general notion that sending unneeded 
O/As is unwise and annoying.

	Thanks,
	Paul