o Paul Kyzivat on 11/23/2011 07:17 PM:
> 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).
I would have thought so, too (and IMO it's the sensible thing to
assume), but RFC 3265 3.2.2. says this:
A NOTIFY request is considered failed if the response times out, or a
non-200 class response code is received which has no "Retry-After"
header and no implied further action which can be taken to retry the
request (e.g., "401 Authorization Required".)
...
If the NOTIFY request fails (as defined above) due to an error
response, and the subscription was installed using a soft-state
mechanism, the notifier MUST remove the corresponding subscription.
A notify error response would generally indicate that something
has gone wrong with the subscriber or with some proxy on the way
to the subscriber. If the subscriber is in error, it makes the
most sense to allow the subscriber to rectify the situation (by
re-subscribing) once the error condition has been handled. If a
proxy is in error, the periodic SUBSCRIBE refreshes will re-
install subscription state once the network problem has been
resolved.
so I don't understand how in RFC 5057, section 5.1, 500 (or unknown
5xx) show up in "Transaction Only" and not in "Destroys Usage" - what
am I missing?
thanks!
Stefan
>
>> 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
>> [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
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
