Re: Updated EDR draft
- From: Nitzan Nissim <
- Subject: Re: Updated EDR draft
- Date: Wed, 17 Apr 2013 18:39:00 +0300
* Can one app access the HTTP session on another app through the
SipWebSocketContext interface? This could be problematic as that can give
an access to a different app SipApplicationSession, and that should
generally not be allowed
* I think that a "close connection" function is not a good idea.
Connections should be handled on the container level only, and since this
affects other apps as well, this will break the basic apps separation model
the SIP Servlets JSR have.
In case there is a genuine need to close connections according to some app
logic, then this should an option that should be made available to all kind
of transports, and on an API that is separated then the application APIs,
and deployed on its own, similar to the custom application router.
An API like that could either :
- listen on incoming and outgoing SIP messages, will not be allowed to
change them, but will use their information or count to decide on closing
the connection they are using
- Can be asked by the applications for connection closing, but will make
the final decision
I guess a decision on that could be made according to actual use cases we
are presented with.
16.4 SIP Outbound Support
* Maybe a better name to the section be "NAT Traversal"? This can
prevent the confusion with the Multihomed outbound concept
* I thought that on Jean last draft it says everything regarded the
keepalive initiation should be done implicitly by the container. I agree
with that and I think that the method flow.sendKeepAlive() method that
leaves that app to the application is wrong. The keepalives are completely
out of the SIP signaling band, and their purpose is to keep connections and
flows open, and so must be the sole responsibility of the container and
transparent to the application. Putting that in the hand of the application
is also error prone, since you can't control the timing in which the method
will be called (the app could be too delayed in calling it, for instance),
and there is a good chance of it being used in the wrong context.
The default keepalive interval could be configured on the application
descriptor, or programmatically, and should be overridden by the value of
the Flow-Timer header received.
I have sent a separate proposal for enhancing this API, and one of the
questions raised I think can be phrased as : "what makes the RFC different
then others that the container needs to performs all those actions instead
of the application."
So other then the reason I laid out in my original note containing the
proposal, I think there are other 2 main reasons why this is different:
1. Differently then some other RFCs rules that are handled on the
application level, this RFC handles not the content of the messages that
affects business logic, but the way the message could reach its
destination. That task should be done as much as possible on the container
level as It actually uses the SIP signaling to 'assist' the lower transport
2. The RFC is fairly complicated. The fact that we need examples to
illustrate how one could use the API in different scenarios shows that it
stands out that way. I believe automating that feature as much as possible
on the container level falls to the same line of logic of letting the
container handle the CANCEL message signaling, answering with ACK to error
to INVITE, etc....
It certainly falls into the same category of making the container API more
friendly to the user similarly to the terminateDialog API. The purpose of
these is to let the container vendor be the SIP expert, while allowing some
of the application composer be experts of their business logic, while
having some SIP knowledge.
From: binod pg
Date: 16/04/2013 06:06 PM
Subject: Re: Updated EDR draft
Sorry for the late reply. I am catching up after my travel last week.
On 4/10/2013 7:28 PM, Lewis, Keith wrote:
Some comments on EDR v03
Regarding section 13 I have sent a separate email.
Here are some of the significant points.
13.1 - why aren't we supporting the websocket client procedures?
As we discussed last week, this will be discussed after submitting early
13.2.3 - a browser may have several jsessionid cookies in progress at
any one time for a server each with a different path corresponding to
different web applications deployed on that server. The current text
asserts that there is a single HttpSession "under which a client is
operating". Either this statement is untrue and section 13.2.3 should
be removed or the text should be expanded to explain it.
The notion of "per client" session is something introduced in HTTP servlet
session semantics. The HttpSession objects are scoped
at the context level. A context is tied to one web application and the http
session is not shared between different contexts by the application.
So, if I understand HTTP specification right, I believe, the statement is
true, since "client" does not indicate a "browser instance".
13.2.5 - The point I was trying to make in last weeks call is that it
is dangerous to allow an application to close a flow which might
still be required by other applications. Some containers might choose
to provide an extension to allow this but we should not provide it in
the standard API nor should we provide an equivalent capability for
TCP connections as the note suggests.
I guess, the consensus we had in the meetings was to make sure that we
leave it there with a note (I further added some comments indicating
that it could affect other applications after last meeting). I also
thought, we are going to review some community feedback from Jean on
the requests for closing the TCP connections. And after EDR, based on all
feedback, we will take a final decision.
Some comments on the outbound section
16.4 - perhaps the title should be changed to "Flow Selection" to
make it clear that the container is providing support for Flows and
not for the whole of RFC5626. Similarly the first paragraph could
describe the API provided in terms of supporting flows.
It is a bit more than Flow, right? For example, a sip container is required
to respond to keep alives (STUN or CRLF), which is not strictly Flow.
I just added a sentence to clarify that.
More over the extension name that we are using is "outbound" as well.
220.127.116.11 - perhaps the title should be "Decoding Flow Tokens".
The fact that the method returns a Flow object does not mean that the
corresponding connection exists or that it currently has keepAlive
It may be better to call the method decodeFlow to make its
We had this discussion in the EG about behavior of Flows w.r.t clustering.
While decoding is what the containers will
do mostly, I thought, the consensus was to not to disallow a potential
custom container logic. So, I agree with Jeans
proposal where we have a getFlow and not decodeFlow.
I still think it would be useful to be able to create a Flow object
from a pair of URIs.
Flow SipFactory.createFlow(SipURI localURI, SipURI remoteURI);
May be we should discuss this separately in the main thread for outbound.
18.104.22.168 - we could remove the example code here and just describe
the functionality offered.
22.214.171.124 - it was useful to show the example to during our internal
discussion but for the spec we could just use text to describe some
examples of when getToken() and decodeFlow() might be used.
Lets try to hear from others whether these examples make sense to be in the
On Sat, Apr 6, 2013 at 7:15 PM, binod pg
Please find the updated EDR draft here.
- Added Outbound chapter.
- Updated with comments.
- Keith's latest e-mail on optionality is not yet handled.
Note: The information contained in this message may be privileged and
and protected from disclosure. If the reader of this message is not
recipient, or an employee or agent responsible for delivering this
message to the
intended recipient, you are hereby notified that any dissemination,
copying of this communication is strictly prohibited. If you have
communication in error, please notify us immediately by replying to
the message and
deleting it from your computer. Thank you. Thrupoint, Inc.