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