SIP protocol - Standing TCP connection
The Session Initiation Protocol (SIP) is a signalling protocol used for establishing and closing multimedia sessions such us voice and video call over the internet. Using SIP is also possible to create video conferencing, streaming multimedia distribution (for online gaming for instance), send instant messages, handle presence information (online/offlie with rich status information). The protocol can be used for creating, modifying and terminating two-party (unicast) or multiparty (multicast) sessions consisting of one or several media streams.
SIP clients typically use TCP or UDP to connect to SIP servers and other SIP endpoints. SIP is primarily used in setting up and tearing down voice or video calls. However, it can be used in any application where session initiation is a requirement. These include Event Subscription and Notification, Terminal mobility and so on. There are a large number of SIP-related RFCs that define behavior for such applications. All voice/video communications are done over separate session protocols, typically RTP.
The following picture describe a basic example of how a SIP session can be established between two parties:
Network Address Translators (NAT) modify the IP address and port information for packets traversing from one network to another. In its most typical example, this is to used to manage private network ranges, and allow them to interract with publicly routed networks.
There are several 'points of impact' where SIP finds NAT problematic, and it is not merely limited to NAT. RTP also has problems with NAT. Because SIP packets go out from a NATed client with their private (and un-routable) IP addresses coded into the message headers and SDP bodies, they are not processed by a NAT device, that operates only on the IP packets as they pass by. This then means that when the packets get to their destination, they are processed and responded to using completley useless source address information.
With standing TCP connections, only one TCP connection is required between two nodes that exchange data. Standing TCP for SIP refers basically to keep open the hole in the NAT from the SIP client to the server. This is normally done by making all SIP clients use a two byte packet which is sent more often than 30 seconds (some routers and firewalls may close the NAT mapping after 30 secs of inactivity).
JAIN SIP is a standard java API for SIP which enable fast development of applications for both desktop and server environments. JAIN SIP is designed for developers who require powerful access to the SIP protocol and it can be utilized in a user agent, proxy, registrar or imbedded into a service container.
The default implementation (and the only one available so far) was originally developed by NIST. In addition to the standard configuration parameters defined by the standard specification of JAIN SIP, NIST provides additional properties which may be useful for applications. For standing TCP, one of the useful properties is "gov.nist.javax.sip.NETWORK_LAYER". By using this property, an application can define its own class "that allows a client to have control over socket allocations and monitoring of socket activity". I have used this property to define an own network layer adapter which implements the standing TCP concept.
The standing tcp socket is created only once, and the NIST implementation makes use of the createSocket method of the NetworkLayer interface when a connection is needed. So, the implementation will create the socket only once and it will trigger a timer to keep it open by sending CRLF charaters out to the network as follows:
Now, the KeepAliveTask is the heart of the standing tcp, and its implementation is straighforward:
SIP clients typically use TCP or UDP to connect to SIP servers and other SIP endpoints. SIP is primarily used in setting up and tearing down voice or video calls. However, it can be used in any application where session initiation is a requirement. These include Event Subscription and Notification, Terminal mobility and so on. There are a large number of SIP-related RFCs that define behavior for such applications. All voice/video communications are done over separate session protocols, typically RTP.
The following picture describe a basic example of how a SIP session can be established between two parties:
Network Address Translators (NAT) modify the IP address and port information for packets traversing from one network to another. In its most typical example, this is to used to manage private network ranges, and allow them to interract with publicly routed networks.There are several 'points of impact' where SIP finds NAT problematic, and it is not merely limited to NAT. RTP also has problems with NAT. Because SIP packets go out from a NATed client with their private (and un-routable) IP addresses coded into the message headers and SDP bodies, they are not processed by a NAT device, that operates only on the IP packets as they pass by. This then means that when the packets get to their destination, they are processed and responded to using completley useless source address information.
With standing TCP connections, only one TCP connection is required between two nodes that exchange data. Standing TCP for SIP refers basically to keep open the hole in the NAT from the SIP client to the server. This is normally done by making all SIP clients use a two byte packet which is sent more often than 30 seconds (some routers and firewalls may close the NAT mapping after 30 secs of inactivity).
JAIN SIP is a standard java API for SIP which enable fast development of applications for both desktop and server environments. JAIN SIP is designed for developers who require powerful access to the SIP protocol and it can be utilized in a user agent, proxy, registrar or imbedded into a service container.
The default implementation (and the only one available so far) was originally developed by NIST. In addition to the standard configuration parameters defined by the standard specification of JAIN SIP, NIST provides additional properties which may be useful for applications. For standing TCP, one of the useful properties is "gov.nist.javax.sip.NETWORK_LAYER". By using this property, an application can define its own class "that allows a client to have control over socket allocations and monitoring of socket activity". I have used this property to define an own network layer adapter which implements the standing TCP concept.
The standing tcp socket is created only once, and the NIST implementation makes use of the createSocket method of the NetworkLayer interface when a connection is needed. So, the implementation will create the socket only once and it will trigger a timer to keep it open by sending CRLF charaters out to the network as follows:
Now, the KeepAliveTask is the heart of the standing tcp, and its implementation is straighforward:
Comments