[OpenSIPS-Devel] [ opensips-Feature Requests-3067207 ] presence out of order NOTIFY

SourceForge.net noreply at sourceforge.net
Mon Sep 20 12:08:35 CEST 2010

Feature Requests item #3067207, was opened at 2010-09-16 03:17
Message generated for change (Comment added) made by anca_vamanu
You can respond by visiting: 

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
>Category: modules
>Group: trunk
Status: Open
Priority: 5
Private: No
Submitted By: Kennard White (kennardwhite)
>Assigned to: Anca Vamanu (anca_vamanu)
Summary: presence out of order NOTIFY

Initial Comment:
Using opensips presence module (HEAD), our clients sometimes get out of order delivery of NOTIFY messages and/or dropped NOTIFY messages. The root cause is that opensips creates multiple, concurrent NOTIFY transactions for the same dialog. This failure could be avoided by queuing subsequent NOTIFY messages until response for prior message is received.

The full details: say opensips creates two concurrent NOTIFY transactions: A and B. The first transmission of A is lost in the network, then B is delivered to the client, and then a retransmission of A is delivered to the client. This is out of order: client gets B before A. Depend upon the client, it will either accept A and process it like normal, drop it A, or send a 500 response to A.

 For full-state events like presence with "good" clients this is a benign failure. But for conference events (RFC4575) which is partial state, this is fatal.

Related info
The resip stack queues outgoing transaction messages to avoid this problem
See discussion: http://www.mail-archive.com/sip-implementors@lists.cs.columbia.edu/msg05638.html


>Comment By: Anca Vamanu (anca_vamanu)
Date: 2010-09-20 13:08

Hi Kennard and Aron,

The problem that you described does indeed appear only for events that
have partial state notifications and in the case of a race causing the
Notify with the lower cseq to get to the client after the Notify with a
higher cseq. The solution that Kennard proposed - to wait for the reply of
the previous Notify is good and will solve this issue. I have changed the
type of this report in feature request and we will try to solve it. Of
course, if you are willing to contribute with the implementation you are
more that welcomed :).



Comment By: Aron Rosenberg (amr42)
Date: 2010-09-16 03:24

Another very common way this can occur is if two PUBLISH messages come in
very close in time. The presence module will start sending out the NOTIFY's
for PUSBLISH 1, and then create a new set of NOTIFY's when PUBLISH 2

PUBLISH 1 and 2 could be from the same endpoint, or from different
endpoints on the same URI.

One use case that tends to trigger this is when a UAC auto changes its
"presence" status upon receiving an incoming call. If an INVITE forks to
two endpoints both endpoints will issue PUBLISH extremmly close in time
causing the presence server to have NOTIFY transactions with multiple CSeq
numbers on the wire at the same time.


You can respond by visiting: 

More information about the Devel mailing list