I've run into some problems when trying to use .refer() in sipunit. I
believe that event ids are handled incorrectly there, but I don't know
the javax.sip well enough to fix that one.
First issue: RFC 3515 says that the subscription for "refer" is
created implicitly (in "2. The REFER Method"). No examples in that RFC
actually include the "Event" in the REFER message. That means, no
REFER responses will have it and so the
ReferSubscriber.validateOkAcceptedResponse() is not correct in calling
eventForMe(). It should not verify either the header or eventid at
that point.
Second issue: The eventid itself... According to "2.4.6 Multiple REFER
Requests in a Dialog" and "2.2 Header Field Support for the REFER
Method" eventid is generated on the transfer-handling side and the
header itself is not supported in user's request. It makes handling
multiple referrals on the user side harder (unfortunately), but some
pbxes (asterisk for example) do assign sequential numbers for eventid.
The simple workaround would be to just disable the eventForMe check
and set "1" as the evenid, so it passes the checks in NOTIFY... but it
should be fixed properly ;)
This is correct - the event header doesn't belong in a REFER request or response at all; and event ID is not required for NOTIFY if there's only one REFER in the dialog.
I think for the ReferSubscriber case, rather than using the last sent request for evaluating event ID (since, as a test tool, SipUnit should allow the test program to send anything even invalid values to the test target), the correct event ID needs to be a separate class attribute for ReferSubscriber that is set to the CSEQ number of the REFER sent out (if I'm correct that no matter what event id is sent in a subsequent SUBSCRIBE, all NOTIFYs for a given REFER subscription (when multiple of them exist on a single dialog) must have the event ID = CSEQ of the REFER request, and if there's only one REFER subscription on the dialog then event ID is optional in received NOTIFYs but if included must be the REFER CSEQ), and for REFER response the event header should be absent, and those things are what needs to be checked for the REFER case (eventForMe(), which at least needs to be overridden by ReferSubscriber and maybe broken up into 2 methods for refer, one for resp handling and one for NOTIFY handling). Needs a little more thinking through and maybe the way expires is handled for REFER can be coupled with that - that was a similar situation where it was different from presence subscribe/notify and needed to be handled differently depending on whether it was a response or a notify, if I recall correctly).
Thanks for finding and reporting this.