Re: [reSIProcate] NOTIFY retransmit, bug or feature?
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.
/a
On 11/18/11 09:44, Nov 18, Robert Szokovacs wrote:
Hi,
I have this setup: a B2BUA based on resip and a mediaserver, based on SEMS.
The SEMS sends a REFER to the resip which starts to send NOTIFYs according to
the progress of the REFERred call: for example: 100, 183,. 180, 200. One of
the NOTIFY gets lost on the network, lets say the 183, the resip retransmits
it, but before the retransmittion, the 180 is sent and replied:
100->
<--OK(100)
183->
...
180->
<-OK(180)
183(r)->
<-500
(resip terminates the subscription)
So the SEMS refuses the retransmitted 183 NOTIFY, because it's cseq is smaller
than the 180's. The SEMS code references the 12.2.2 section of the RFC, I
presume this part:
"
If the remote sequence number was not empty, but the sequence number
of the request is lower than the remote sequence number, the request
is out of order and MUST be rejected with a 500 (Server Internal
Error) response.
"
https://tools.ietf.org/html/rfc3261#section-12.2.2
I guess one of the peers behaviour is wrong, otherwise any random hickup could
terminate the subscription. Which one is the correct behaviour?
Thank you!
br
Szo
_______________________________________________
resiprocate-devel mailing list
resiprocate-devel@xxxxxxxxxxxxxxx
https://list.resiprocate.org/mailman/listinfo/resiprocate-devel