Containers are likely to clone the SipServletRequest when the
derived session is created.
Ok, I think you lost me but I guess my original question
was also that
> Why do we need to pass in the SipSession? If we
do, it seems like this
> method should be on the SipSession as opposed to
the request. Since it
> is on the request, I would assume this method
would only return
> responses for this particular transaction,
correct? And if so, the
> SipSession is not needed since the request you
are operating on
> explicitly is associated with a SipSession, or
perhaps I'm missing
> Version 2 of my proposal did have this method on
the SipSession. I realised
> a problem with that as explained in the email
that accompanied version 3.
> The rseq value in a reliable provisional is only
unique for that dialog. Due
> to forking there can be several dialogs which
return provisional responses.
> In order to locate a specific response at a UAC
which is downstream of a
> forking proxy we need to pass the session (or
derived session) along with
> the rseq to the method on SipInviteRequest.
> If we put the method on the SipSession there is
still a problem with the
> uniqueness of the rseq value. PRACK can arrive
after the corresponding ACK
> by which time a new INVITE transaction can be in
progress which also has
> provisional responses. To retrieve the correct
response we would need to
> pass it the requestId of the INVITE transaction
as well as the rseq.
> It seems best to avoid cluttering the SipSession
interface with methods such
> as this one.
the request itself is uniquely associated with a
session (it cannot have two) so if you ask the request,
session is implied. Right?
A SIP request is uniquely associated with a SIP dialog,
which is uniquely associated with a SipSession. This all
seems simple enough, until you consider forking. When
downstream forking occurs, you will have more than one
SipSession, but still only have one SipServletRequest.
This is not so bad when you are acting as a UAC, but when
you are running a B2BUA and acting as a UAS, what happens
when you want to "fork back" to the caller?
Alice B2BUA Proxy Bob1
Here we have an example of parallel downstream forking.
Assume that the B2BUA is an app running on a SipServlet
container. Everything else is a normal SIP actor outside
of the container. At step (9), the response from Bob2
leads the container to realise that forking has occurred,
and so it creates a derived SipSession from the session
used to send the initial INVITE to Bob in step (2). When
we need to send the first response to Alice in (7), then
the existing SipSession is used, but to create the second
response in (10) requires a new SipSession to be created.
After all this forking: Alice has two SipSessions, but
only one INVITE SipServletRequest - when that
SipServletRequest is queried for Alice each has one
INVITE. When you call getSession() on the INVITE
SipServletRequest, it will return the original SipSession.
All quite weird.
So, though I see your point, we can not assert that there can be
more than one sipsession
for a sipservlet request.
Anyway, I suck at the prack stuff so I'm going to go with
want as long as we make sure that the methods are clear,
documentation is there and we don't run the risk of
container implementors as well as users.
As for the PRACK stuff, we are discussing this and
Keith is writing up a further proposal that is hopefully a
little more clear when it comes to handling PRACK
transactions from one INVITE transaction overlapping with
a different INVITE transaction (and thus possibly
overlapping with its PRACK transactions).
Sure, but until you get a final response the "other" type
>> --- SipSession.getActiveInvites ---
>> What about getActiveXXX? i.e., what about all
the other methods?
> Only INVITE transactions require an ACK, other
transactions are complete
> once the final response is sent/received. Similarly
only INVITES can have
> reliable provisional responses.
are still "active". And if you are after only whether or
not you have
received an ACK or not, wouldn't a method following the
getUnacknowledgedXXXX methods be more appropriate?
Tom Strickland, Software
Developer, Thrupoint Software. Tel: +44 (0)
Note: The information contained in this message may be privileged and confidential
and protected from disclosure. If the reader of this message is not the intended
recipient, or an employee or agent responsible for delivering this message to the
intended recipient, you are hereby notified that any dissemination, distribution or
copying of this communication is strictly prohibited. If you have received this
communication in error, please notify us immediately by replying to the message and
deleting it from your computer. Thank you. Thrupoint, Inc.