Subject: [Sip] info-events and "in-order delivery"

From: Jeroen van Bemmel <[email-masked]>
Date: Sat, 25 Oct 2008 13:22:21 +0200

The current info-events text says (section 5.6):

"In addition, the INFO method does not define mechanisms for ensuring
   in-order delivery.  While the UAC will increment the CSeq header upon
   the transmission of new INFO messages, the UAS cannot use the CSeq to
   determine the sequence of INFO information.  This is due to the fact
   that there could be gaps in the INFO message CSeq count caused by a
   user agent sending re-INVITES or other SIP messages."

This is not entirely accurate: SIP guarantees that INFO messages are never delivered out-of-sequence. 
Only in case of *overlapping INFO requests* (i.e. sending a next one before having received a final 
response for the previous one) it cannot be guaranteed that all are received.

The partial event mechanism (RFC5263) includes a 'version' attribute to detect such gaps. In case of INFO events, 
I think it is better to simply say: the UAC MUST NOT send an INFO request with a given event type when a previous 
INFO request containing that event type has not yet received a final response.

Regards,
Jeroen

_______________________________________________
Sip mailing list  https://www.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: Paul Kyzivat <[email-masked]>
Date: Sat, 25 Oct 2008 10:09:43 -0400

Jeroen,

There may be some utility to overlapping info packages of the *same* 
package type. This can work if subsequent messages *supersede* the 
preceding one, so if a later one is processed first then the loss of the 
earlier one is irrelevant. But this is much less likely to be the case 
for packages of *different* types.

I think this simply needs to be highlighted as an issue - especially the 
cross-package-type issue. The details need to be addressed on a 
per-package-type basis.

	Thanks,
	Paul

Jeroen van Bemmel wrote:
> This is not entirely accurate: SIP guarantees that INFO messages are 
> never delivered out-of-sequence. Only in case of *overlapping INFO 
> requests* (i.e. sending a next one before having received a final 
> The partial event mechanism (RFC5263) includes a 'version' attribute to 
> detect such gaps. In case of INFO events, I think it is better to simply 
> say: the UAC MUST NOT send an INFO request with a given event type when 
> a previous INFO request containing that event type has not yet received 
> a final response.
> 
> Regards,
> Jeroen
> 
>