On 11/23/11 9: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,
The main problem here is that the "A" stack should not terminate the
subscription. This error should only affect the NOTIFY transaction at
hand. (See RFC 5057, section 5.1).
> 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?
There is a general issue with overlapping NOTIFYs if one gets lost or
delayed, which you are seeing here. The proper way to deal with this
depends on the details of the event package. For some event packages it
can cause a real mess and the only good solution is to delay sending the
next notify till the last one is known to have been received.
But in other cases, like this one, it doesn't really matter much if one
is lost as long as a subsequent one is received. So in this case its
sufficient for "A" to send then as the state changes, so long as it
properly handles a 500 response - by just ignoring it when a subsequent
notify is known to have been sent.
> Should the "B" stack accept out-of-order NOTIFYs?
NO!
Thanks,
Paul
> Thank you in advance!
>
> br
>
> Szo
>
>
> _______________________________________________
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
