I dont think there is any rule that prohibits notifies to overlap.
Although as you have stated here, it might get you in trouble if you do
not serialize your transactions. Failure of the REFER due to the NOTIFY
getting a 500 does not terminante the INVITE usage so the call should
still proceed. My vote goes to making the UAC serialize notifies so it
does not get into this kind of trouble.
On 11/23/2011 09:21 PM, Robert Szokovacs wrote:
> Hi,
>
> I have the following setup: a B2BUA based on sipstack "A" and a mediaserver,
> based on sipstack "B".
> Themediaserver sends a REFER to the B2BUA 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 "A"
> stack retransmits it, but before the retransmittion, the 180 is sent and
> replied:
>
> 100->
> <--OK(100)
> 183->
> 180->
> <-OK(180)
> 183(r)->
> <-500
> ("A" stack terminates the subscription)
>
> The "B" stack refuses the retransmitted 183 NOTIFY with 500, because it's cseq
> is smaller than the 180's, which seems correct as per 12.2.2 of RFC3261:
> "
> 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.
> "
>
> The "A" stack in turn terminates the subscription and the transaction dies,
> because the mediaserver application expects to receive more NOTIFYs, at least
> one with "subscription-state: terminated", but it never comes. The "B" stack
> doesn't notify the mediaserver application, so has no way of knowing something
> went wrong.
>
> What would be the correct behavior?
> Should the B2BUA hold the sending of the next NOTIFY until it doesn't receive
> reply to the last one?
> Should the "A" stack marshall the NOTIFYs and make sure they don't get out of
> order?
> Should the "B" stack accept out-of-order NOTIFYs?
>
> Thank you in advance!
>
> br
>
> Szo
>
>
> _______________________________________________
> Sip-implementors mailing list
> [email protected]
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
