[reSIProcate] Some more ponderings about REFER subscription
Hi,
The commit
http://list.resiprocate.org/archive/resiprocate-commit/msg06036.html
started some discussion between our application developers and I'd like to
have your opinion too:
a, If a new REFER request (new: there is no active subscription associated
with it yet) includes an Event header and it also includes an Id parameter,
should that be used to as SubscriptionId or it must be forced to be equal
CSeq?
(the current code forces it to be CSeq, since the BaseSubscription's
constructor runs first, sets mSubscriptionId, then ServerSubscription's
constructor overwrites it.)
I couldn't find a definative answer in the RFCs, only RFC 3515 2.4.6 kind of
point into the direction of let's force it, but I'm not sure it forbids the
client from using any Id he likes if he doesn't care about NOTIFYs but do want
to cancel the subscription with "expires=0". It's not really a good idea, of
course.
b, If someone uses a single REFER (most users I guess) and later wants to
unsubscribe using another REFER with "expires=0", can he legally expect to do
so without including an Event header with the correct Id parameter (being
equal the CSeq of the original REFER)? Before the mentioned commit it did
work, because in case of missing Event header we considered all REFER
subscriptions matching. Now this kind of unsubscribe will not work, but I
haven't find any indication that it should work according to the RFCs. On the
other hand RFC 3265 3.1.2 explicitly states that the SUBSCRIBE request must
include an Event header, so I think the correct behavior is the one implemted
in this commit, even if it breaks some existing code.
Any toughts would be appreciated!
br
Szo