Lets ask Adam to comment on this.
Adam?
Thanks,
Paul
On 11/24/11 7:56 AM, Stefan Sayer wrote:
> 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
