o Robert Szokovacs on 11/23/2011 11:20 AM:
On 2011 November 22, Tuesday 23:20:10 SZOKOVACS Robert wrote:
On 2011. November 22., Stefan Sayer wrote:
Hi,
if the B2BUA is ending the (event notification-) dialog created by the
REFER when it receives the 500, it's broken, the 500 reply does not
end that dialog.
upon rereading relevant rfcs, looks like this is actually correct:
3.2.2. Notifier NOTIFY Behavior
...
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.
Sorry, I forgot to mention, B2BUA doesn't end the dialog, only ends the
subscription, doesn't send any more NOTIFY. (actually, the B2BUA is built upon
resiprocate, and resiprocate notifies the application that the other side
(SEMS in our case) has terminated the subscription.)
What I really want to find out is what should I fix, resiprocate, my
application or SEMS? :)
to me it looks like the behaviour of every one is actually correct
(i.e., ask sip-implementors? =).
maybe the application should refresh the subscription if it doesnt
receive NOTIFYs for a while?
Regarding the original situation: is the retransmission legal? Or sending a
new NOTIFY without receiving a 200 for the old one illegal to begin with?
I don't see anything which limits the number of concurrent notify
transactions (unlike INVITE transactions for example).
Stefan
TIA
br
Szo
_______________________________________________
Semsdev mailing list
[email protected]
http://lists.iptel.org/mailman/listinfo/semsdev
--
Stefan Sayer
CEO (Geschäftsführer)
FRAFOS GmbH
email: [email protected]
mobile:+49 162 1366449
www.frafos.com
Prinzessinnenstr. 19/20 betahaus
10969 Berlin
Germany
_______________________________________________
Semsdev mailing list
[email protected]
http://lists.iptel.org/mailman/listinfo/semsdev
