SI
SI
discoversearch

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor.  We ask that you disable ad blocking while on Silicon Investor in the best interests of our community.  If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.
Technology Stocks : AUTOHOME, Inc
ATHM 23.93+1.1%3:59 PM EST

 Public ReplyPrvt ReplyMark as Last ReadFilePrevious 10Next 10PreviousNext  
To: Frank A. Coluccio who wrote (2544)7/21/1998 9:40:00 PM
From: ahhaha  Read Replies (1) of 29970
 
It isn't even that good, because they put an SP on the patch!

A Protocol for Real-time Collaboration

By Tom Nolle. LANTIMES, 7/20/98

For real-time IP video and voice communications to be
successful, they'll have to provide most of the facilities of
public telephony, or users will constantly encounter
restrictions that reduce their perception of the value of
IPbased facilities. A newly proposed technologySession
Initiation Protocol, or SIPcould help meet this requirement.
TCP/IP networks tend to assume that network resources such as
servers are always connected and can be located through
directories such as DNS. User and client systems are not
usually assumed to be permanent network residents, so they may
not have DNS entries or even fixed IP addresses. Most clients
either talk to servers (in which case the server knows the
client ID from the source IP address field) or send E-mall to
other clients (in which case the two parties never communicate
directly).

On the other hand, collaborative relationships,
including some forms of IP telephony, assume that client systems
can "call" one another and communicate in real time. That can
be done today if you know the IP address of the partners and if
they're all available. SIP could mediate between the network
and the collaborators.

The protocol divides the world into SIP servers and
SIP clients, with the latter representing multimedia
collaborative users. The purpose of the SIP server is to
facilitate the conferencing process by providing a central place
where user addresses can be found and conferencc invitations can
be issued. A conference moderator sends an invitation message
to a SIP server which the server forwards to the designated people to
join the conference. SIP systems (clients and servers) can also
provide other facilities, such as forwarding, redirection, and
registration.

For IP to challenge public telephony as we know
it, SIP is an essential element. It provides a way to call
partners using a logical name that can be registered directly in
a SIP directory or inherited through a protocol such as LDAP
(Lightweight Directory Access Protocol) from other directories,
including DNS. SIP also provides call progress signals such as
"Busy," "Ringing," and "Don't bother me."

Because SIP has a rich set of calling features, it
would be relatively easy to build a gateway between SIP and a
telephone signaling protocol such as simple touch-tone dialing
or the internal voice network's Signaling System 7. RBOCs and
some other facility-based carriers are already asking vendors
for SIP support on any IP telephony RFP they issue.

SIP overlaps the H.323 protocol but addresses a space
in which H.323 is relatively quiet. Session initiation and
conference control in H.323 are based on a subset of H.245 and T
124, which also are referenced in the SIP model. But SIP
provides more facilities, and it may eventually be included in
H.323 to define session control in IP networks.

Network implications

SIP is primarily a client or server software issue.
Any IP telephony application could be made a SIP client, and a
SIP server could reside anywhere in a network on a standard
server hardware platform. Some Unix implementations are already
available.

Network transport infrastructure might benefit from
being SIP-aware as well. This is particularly true for networks
based on mapping IP to a virtual circuit protocol such as ATM,
including ATM's LANE (LAN Emulation) and MPOA (MultiProtocol
Over ATM).

This dependency occurs because a SIP conference would
probably benefit from some additional QoS (Quality of Service),
and with IP-over-ATM implementations, this would be easily
handled when the virtual circuit that represents the application
flow is first set up. A switch that provides internal SIP
services (as some LAN switches already provide directory
services) would know when such an SIP session was being
established and could set the QoS accordingly.

Despite what many vendors will say, SIP is not
explicitly an IP telephony protocol. It is part of a whole
group of multimedia protocols, including a Session Activation
Protocol and a Session Description Protocol, that come out of
the IETF's MMUSIC (Multiparty, Multimedia Session Control)
apecification. By nature, then, SIP is targeted more at
collaboration than simple IP phone calls.

There is no question that this protocol is going to
be the focus of a lot of IP telephony interest for its
sophisticated emulation of public telephone calling features.
But SIP doesn't affect speech quality issues, which remain
(along with regulatory issues) the greatest barriers to IP voice
acceptance.
Report TOU ViolationShare This Post
 Public ReplyPrvt ReplyMark as Last ReadFilePrevious 10Next 10PreviousNext