Re: [reSIProcate] NOTIFY retransmit, bug or feature?
On 2011 November 23, Wednesday 23:38:15 you wrote:
> In this case, resip is doing what RFC 3265 literally says to do in
> section 3.2.2. Based on implementor experience, we determined that this
> removal behavior is too aggressive. This revised understanding is
> reflected in RFC 5057, which says that the 500 response should merely
> fail the transaction (rather than kill the usage).
>
> This is a known and reported bug in RFC 3265 (see
> http://bugs.sipit.net/show_bug.cgi?id=744), and will be addressed in the
> almost-finished revision to that document (see
> http://tools.ietf.org/html/draft-ietf-sipcore-rfc3265bis-04#section-4.2.2).
>
> Resip should be updated to reflect the rules in RFC 5057. It would also
> be a good idea to update its notifier logic so that it can have only one
> NOTIFY pending in a dialog at any one time (to prevent subscribers from
> taking harmful actions based on cseq misordering), but that isn't
> strictly necessary for protocol compliance.
Hi,
As it turns out, resip has changed in it's behavior, in 1.7 it's doing what
you just described above (sorry about the confusion, I noticed the problem in
1.5, checked the RFC, saw resip was doing the right thing (didn't know about
the update), so I thought that behavior was here to stay. Then upgraded to 1.7
to see if that avoids sending NOTIFY-es out-of-order, and noticed that it did
not kill the subscription any more).
On the other hand, even if the resiprocate's notifier logic stays the same,
the application developer should be provided with an API to be able to
serialize the NOTIFYs. Currently, there is no callback called when the OK
arrives in response to a NOTIFY (see resip/dum/ServerSubscription.cxx:296)
br
Szo