Likely to clone the SipServletRequest when the derived
session is created? I've probably missed this (it wouldn't be
the first time :-) but...
Where in the spec does it say that they should/may/must create
the cloned request? Quoting from the spec:
--- Start-quote ---
126.96.36.199 Derived SipSessions
A derived SipSession is essentially a copy of the SipSession
associated with the original request. It is constructed at the
time the message creating the new dialog is passed to the
application. The new SipSession differs only in the values for
the tag parameter of the address of the callee (this is the
value used for the To header in subsequent outgoing requests)
and possibly the route set. These values are derived from the
dialog-establishing message as defined by the SIP
specification. The set of attributes in the cloned SipSession
is the same as that of the original—in particular, the values
are not cloned.
New SipSessions corresponding to the second and subsequent 2xx
responses (or 1xx responses with To tags) are available
through the getSession method on the SipServletResponse. The
“original” SipSession of the request continues to be available
through the original request object.
12.5 Original Request and Session Cloning
The incoming request that results in creation of a SipSession is
termed as the original request, a response to this original
request can be created by the application even if the request
was committed and application does not have a reference to this
request. This is necessary because the B2BUA application may
require to send more than one successful response to a request.
For example, when a downstream proxy forked and more than one
success responses are to be forwarded upstream. This can only be
required on initial requests, as only original requests shall
need such multiple responses.
status, String reasonPhrase) throws IllegalStateException;
The response thus generated MUST have a different "To" tag from
the other responses generated to the request and must result in
a different SipSession. In this (and similar) cases the
container clones the original SipSession for the second and
subsequent dialogs, as detailed in 188.8.131.52 Derived SipSessions.
The cloned session object will contain the same application data
but its createRequest method will create requests belonging to
that second or subsequent dialog, that is, with a "To" tag
specific to that dialog.
--- End-quote ---
Common sense would suggest that it would be useful if the
container cloned the request, but I don't read this text as
implying that the container may/should/must do this. I would
say that it must, but there is nothing that I can lean on in
the spec text as an app developer that would allow me to rely
on that hope :-)