|
| |
Protocol
Protocol design
SIP clients use TCP or UDP typically using port 5060 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.
A motivating goal for SIP was to provide a signaling and call setup protocol for
IP-based communications that can support a superset of the call processing
functions and features present in the public switched telephone network (PSTN).
SIP by itself does not define these features; rather, its focus is call-setup
and signaling. However, it has been designed to enable the building of such
features in network elements known as Proxy Servers and User Agents. These are
features that permit familiar telephone-like operations: dialing a number,
causing a phone to ring, hearing ringback tones or a busy signal. Implementation
and terminology are different in the SIP world but to the end-user, the behavior
is similar.
SIP-enabled telephony networks can also implement many of the more advanced call
processing features present in Signalling System 7 (SS7), though the two
protocols themselves are very different. SS7 is a highly centralized protocol,
characterized by highly complex central network architecture and dumb endpoints
(traditional telephone handsets). SIP is a peer-to-peer protocol. As such it
requires only a very simple (and thus highly scalable) core network with
intelligence distributed to the network edge, embedded in endpoints (terminating
devices built in either hardware or software). SIP features are implemented in
the communicating endpoints (i.e. at the edge of the network) as opposed to
traditional SS7 features, which are implemented in the network.
Although many other VoIP signaling protocols exist, SIP is characterized by its
proponents as having roots in the IP community rather than the telecom industry.
SIP has been standardized and governed primarily by the IETF while the H.323
VoIP protocol has been traditionally more associated with the ITU. However, the
two organizations have endorsed both protocols in some fashion.
SIP works in concert with several other protocols and is only involved in the
signaling portion of a communication session. SIP acts as a carrier for the
Session Description Protocol (SDP), which describes the media content of the
session, e.g. what IP ports to use, the codec being used etc. In typical use,
SIP "sessions" are simply packet streams of the Real-time Transport Protocol (RTP).
RTP is the carrier for the actual voice or video content itself.
The first proposed standard version (SIP 2.0) was defined in RFC 2543. The
protocol was further clarified in RFC 3261, although many implementations are
still using interim draft versions. Note that the version number remains 2.0.
SIP is similar to HTTP and shares some of its design principles: It is human
readable and request-response structured. SIP shares many HTTP status codes,
such as the familiar '404 not found'. SIP proponents also claim it to be simpler
than H.323. However, some would counter that while SIP originally had a goal of
simplicity, in its current state it has become as complex as H.323. Others would
argue that SIP is a stateless protocol, hence making it possible to easily
implement failover and other features that are difficult in stateful protocols
such as H.323. SIP and H.323 are not limited to voice communication but can
mediate any kind of communication session from voice to video or future,
unrealized applications.
| |
|
