Forking can lead to 'derived' SipSessions. The label 'derived' only really matters for the act of copying the parent session, as after that, all sessions should be considered to be equivalent: it does not really matter which session was the first, as what really matters is the final response to each session. If session 5 receives a 200 ok and the application wants to terminate the remaining sessions, then it which session is the original session and which are derived does not matter. So, a better label: sibling sessions.
The requirement: the means to discover sibling SipSessions for a given SipSession. Perhaps a method call SipSession.getSiblingSessions(): Set<SipSession>, returning empty set if there are none.
A secondary requirement: the means to terminate other SipSessions by calling SipSession.terminateOtherSipSessions(). This is a more complicated requirement: it is relatively straightforward in non-proxy scenarios, but in proxy scenarios all that we can do is to terminate such branches.
I will have more to add on this topic shortly: this is just an initial bug-report.