Skip to main content

Re: 2.0 Spec v7 - 18.4 Client Initiated Connections

  • From: binod pg < >
  • To:
  • Subject: Re: 2.0 Spec v7 - 18.4 Client Initiated Connections
  • Date: Wed, 12 Feb 2014 09:43:46 +0530
  • Organization: Oracle Corporation

Hi Keith,

As much as I appreciate ideas and and the effort you are putting into the review of the
specification, as you noted below, this section has undergone numerous rounds of review
even before EDR.

I would suggest we document these ideas for a future release of the specification.

thanks,
Binod.

On 2/12/2014 1:12 AM, Keith Lewis wrote:
An alternative to my last suggestion would be a SipConnection interface as hinted at by Jonas.

Here is how it might be used

 1. Provide SipServletMessage.getConnection() and
    getInitialConnection() deprecate the existing SipServletMessage
    methods getLocalPort, getLocalAddr, getRemoteAddr, getRemotePort,
    getInitialRemoteAddr, getInitialRemotePort, getTransport,
    getInitialTransport.
 2. getConnection() returns null for a locally generated response or a
    message that has not yet been sent.
 3. Use the SipConnection object for calls to SipSession.setFlow and
    the like. Could rename these methods to setConnection(). Also have
    a getConnection() on these objects.
 4. SipServletContext has the following methods -
    getSipConnection(flowToken), getSipConnection(localSocketAddr,
    remoteSocketAddr)
 5. SipConnection has methods getTransport), getLocalSocketAddress(),
    getRemoteSocketAddress(), isLocallyRouted(), getFlowToken(),
    isFlow(), releaseOutgoingFlow(), isValid(),  getDirection(), and
    registerListener(listener).
 6. If getProtocol() returns the value for a Websocket then the
    Connection can be cast to a SIpWebsocketConnection which has the
    method getHttpUrl();

getDirection() - this would return INCOMING or OUTGOING.
isLocallyRouted() - true if the remote SocketAdress is the same as the local SocketAddress.

The registerListener() method would allow an application to express an interest only in some of the connections - at present any application with a listener gets informed of ALL flows that fail.

Keith Lewis


On 11 February 2014 18:06, Keith Lewis < <mailto: >> wrote:

    All,

    I know we have already had a lot of discussion on 18.4 but I
    thought I would float a suggested change to see what people think.

    The notion of a flow defined here is almost the same as the
    existing notion of a sip "connection". I suggest we remove the
    Flow interface and have a more generic ConnectionId object.

    I suggest that ConnectionId should be a value class that holds the
    local and remote address/port pair.
    This allows it to be easily serialized and passed around (e.g.
    stored in a registrar).

    Here is how it might be used

     1. Constructor of ConnectionId takes a local and remote
        InetSocketAddress.
     2. ConnectionId has methods getLocalSocketAddress,
        getRemoteSocketAddress, isLocallyGenerated, isLocallyRouted
        and getFlowToken.
     3. Provide SipServletMessage.getConnectionId() and
        getInitialConnectionId() deprecate the existing
        SipServletMessage methods getLocalPort, getLocalAddr,
        getRemoteAddr, getRemotePort, getInitialRemoteAddr,
        getInitialRemotePort.
     4. Use theConnectionId object for calls to SipSession.setFlow and
        the like. Could rename these methods to setConnection(). Also
        have a getConnection() on these objects.
     5. Provide a getFlowManager() method on SipServletContext. There
        could also be a built in CDI bean. Just like the new
        DnsResolver object.
     6. FlowManger interface (or ConnectionManager?) has the following
        methods - decodeFlowToken(token),
        releaseOutgoingFlow(connectionId),
        isConnectionActive(connectionId), getDirection(connectionId),
        and registerListener(connectionId, listener).

    getDirection() - this would return INCOMING or OUTGOING.

    The registerListener() method would allow an application to
    express an interest only in some of the connections - at present
    any application with a listener gets informed of ALL flows that fail.

    Keith Lewis



--------------------

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. CafeX Communications.




2.0 Spec v7 - 18.4 Client Initiated Connections

Keith Lewis 02/11/2014

Re: 2.0 Spec v7 - 18.4 Client Initiated Connections

Keith Lewis 02/11/2014

Re: 2.0 Spec v7 - 18.4 Client Initiated Connections

binod pg 02/12/2014
 
 
Close
loading
Please Confirm
Close