Skip to main content

Nitzan's comments [Re: Updated EDR draft]

  • From: Binod < >
  • To:
  • Subject: Nitzan's comments [Re: Updated EDR draft]
  • Date: Thu, 18 Apr 2013 21:25:06 +0530
  • List-id: <jsr359-experts.sipservlet-spec.java.net>

On Wednesday 17 April 2013 09:09 PM, Nitzan Nissim wrote:
13 WeSockets:

        * 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
HTTP session is accessible only within the same converged application.


        * 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.
We had discussed some usecases some time back. I am fine with revisiting
this after EDR, with feedback (if any) from the community.


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

How about "Managing Client Initiated Connections"? Which is the title of
5626.


        * 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
level.

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, whinle
having some SIP knowledge.
As we discussed yesterday, lets continue the discussion in the coming weeks
and try to refine the APIs. Thanks for your proposal.

- Binod.



Nitzan






From:   binod pg 
< >
To:     
,
Date:   16/04/2013 06:06 PM
Subject:        Re: Updated EDR draft



Hi Keith,

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
draft.


       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.


       16.4.1.1 - 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
       running.

       It may be better to call the method decodeFlow to make its
       functionality clear.

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.

       16.4.1.2 - we could remove the example code here and just describe
       the functionality offered.

       16.4.1.5 - 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
spec.

thanks,
Binod.


       Keith


       On Sat, Apr 6, 2013 at 7:15 PM, binod pg 
< >
 wrote:
         Please find the updated EDR draft here.

         
http://java.net/projects/sipservlet-spec/downloads/download/v0.3/jsr359-v03.pdf

         
http://java.net/projects/sipservlet-spec/downloads/download/v0.3/jsr359-javadoc-v3.zip


         Notes:
         - Added Outbound chapter.
         - Updated with comments.
         - Keith's latest e-mail on optionality is not yet handled.

         thanks,
         Binod.


       --------------------
       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.
       nXaR2cC3










Updated EDR draft

binod pg 04/06/2013

Re: Updated EDR draft

Lewis, Keith 04/10/2013

Re: Updated EDR draft

binod pg 04/16/2013

Re: Updated EDR draft

Nitzan Nissim 04/17/2013

Nitzan's comments [Re: Updated EDR draft]

Binod 04/18/2013
 
 
Close
loading
Please Confirm
Close