Friday, 31 August 2012
Tuesday, 28 August 2012
The greatest championship tennis point ever
http://www.youtube.com/watch?v=3-xjAL5Mj5I
Best game of tennis ever
http://www.youtube.com/watch?v=DDm3XH0cXRM
Murray played an excellent shot which came from now where!!!!!!!! Please share and like
Monday, 27 August 2012
U-19 world cup final winning moments
India win by 6 wickets and are the ICC U19 World Cup Champions, the Indian players rush onto the field and they are very much excited and so are the fans.
http://www.youtube.com/watch?v=2lKk_bIgVEQ
Chand is draped with the Indian flag, who has played an excellent knock.
Chand is draped with the Indian flag, who has played an excellent knock.
Incredible stuff by defender
Sunday, 26 August 2012
First man on moon Neil Armstrong dies 82
Neil
Armstrong was a quiet, self-described “nerdy” engineer who became a
global hero when as a steely nerved US pilot he made “one giant leap for
mankind” with the first step on the moon.
The modest man who entranced and awed people on Earth has died. He was 82.
Armstrong died Saturday following complications resulting from
cardiovascular procedures, a statement from his family said. It didn’t
say where he died.
Armstrong commanded the Apollo 11 spacecraft
that landed on the moon July 20, 1969, capping the most daring of the
20th century’s scientific expeditions.
Armstrong died Saturday following complications resulting from cardiovascular procedures, a statement from his family said. It didn’t say where he died.
Armstrong commanded the Apollo 11 spacecraft that landed on the moon July 20, 1969, capping the most daring of the 20th century’s scientific expeditions.
Saturday, 25 August 2012
Wednesday, 22 August 2012
H.323 versus SIP: A Comparison
H.323 versus SIP: A Comparison
(Here's an at-a-glance protocol comparison for people with really short attention spans!)Like everything else on the web, this is a living document which we will be updating as the standards evolve. In fact, there is much work in progress for both H.323 and SIP, but, in order to compare apples to apples and make this comparison meaningful, we have chosen to focus on what is currently defined rather than on what might be defined in the future. Also, note that commentary that is not vital to the main comparison text appears in a smaller font immediately below it.
| H.323 | SIP | |
|---|---|---|
| Philosophy | H.323 was designed with a good understanding
of the requirements for multimedia communication
over IP networks, including audio, video,
and data conferencing. It defines an entire,
unified system for performing these functions,
leveraging the strengths of the IETF and
ITU-T protocols.
As a result, it might be reasonable for users to expect about the same level of robustness
and interoperability as is found on the PSTN today, although this admittedly varies across the globe.
Only those features that are necessary for a particular application need to be supported. For example, a VoIP application of course does not need to support the rich video features of H.323. | SIP was designed to setup a "session"
between two points and to be a modular,
flexible component of the Internet architecture. It has a loose concept
of a call (that being a "session"
with media streams), has no support for multimedia
conferencing, and the integration of sometimes
disparate standards is largely left up to
each vendor.
As a result, it might be reasonable for users to expect about the same level of robustness
and interoperability as is found on the Internet today, e.g., varying levels of
compatibility between web sites and browsers, missing browser plugins, dead links,
seemingly empty emails, email that is not delivered, and email that cannot be replied to.
At least with the Internet, one often has desktop tools to cope with these problems, e.g.,
another browser or email client to try and the ability to look at the actual email headers.
With an embedded, inaccessible application running on, for example, a telephone,
this human intervention is not possible.
Philosophically, the difference between H.323 and SIP may be freedom/chaos on one hand and structure/dependability on the other, although where H.323 and SIP are located along that axis is debatable. SIP loosely supports conferencing via re-INVITE; however, it lacks all the capabilities for performing conference control, such as the ability to eject users from a conference. In addition, there are no standard tools for data collaboration (electronic whiteboard, application sharing, etc.). RFC 3261 states that "SIP does not offer conference control services." However, in all areas where SIP, proper, is lacking, one might be able to use it in conjunction with another standard that provides the needed functionality. |
| Reliability | H.323 has defined a number of features to handle failure of intermediate network entities. For example, if a gatekeeper fails, the protocol is designed to utilize an alternate gatekeeper. If a call that is being routed through intermediate signaling entities fails, H.323 has the wherewithal to re-route the call to an operational entity so that the call is not disrupted. | SIP has not defined procedures for handling device
failure.
If a SIP user agent fails, there is no means for the proxy to detect that failure
except by having the proxy send INVITE messages to the device and
waiting for them to timeout. Moreover, if a SIP proxy fails, the SIP user
agent has no means of detecting that failure.
In addition to pre-call failure problems, there are no mechanisms within SIP to recover a call that is in progress. Of course, since SIP is the Session Initiation Protocol, this stands to reason. Nonetheless, service providers and customers alike would be very unhappy to simply lose their active calls. Some procedures for reliability and load-sharing in locating a SIP server (not for mid-call failure, though) are defined in an IETF draft document; however, it has no force. The guidelines for writing these drafts states, "Internet-Drafts [...] should not be cited or quoted in any formal document." and "The Internet-Draft should neither state nor imply that it has any standards status;..." |
| Message Definition | ASN.1,
a standardized, extremely precise, easy-to-understand
structural notation that is used by many other systems.
The message codec, or encoder and decoder, can be automatically generated
directly from the original, as-published ASN.1 specification using a commercial or free ASN.1
compiler.
Whenever the specification changes, one only has to rerun the compiler to generate a new codec. One could also implement the codec by hand. |
ABNF, or Augmented Backus-Naur Form,
a syntactical
notation. SIP uses the ABNF as defined in
RFC 2234.
The message codec cannot be automatically generated directly from the
original, as-published ABNF specification. One must use an ABNF parser or manually translate the specification to
one or more grammars, such as that used by
yacc/lex
or antlr, (unlike most programming languages, for example,
SIP does not use a context-free grammar) interspersed with user-provided code
and then run the corresponding parser generator to generate the decoder.
But this only works for the decoder--one must always implement the encoder by hand.
When the original ABNF specification changes, one must (again) modify the encoder by hand, manually translate the specification modifications to corresponding grammar modifications, and then run the parser generator to generate a new decoder. This is an error-prone process, and one can never be sure that the original specification has been correctly translated to the parser-generator's grammar. As with H.323, one could also implement the codec completely by hand. |
| Message Encoding | H.323 encodes messages in a compact binary
format that is suitable for narrowband and broadband connections.
Most Internet protocols are binary, e.g., IP, TCP, UDP, ICMP, DNS,
LDAP, SNMP, RADIUS, NTP, DHCP, and SSH, and for
those that are text, there are or
have been efforts to provide a binary form, e.g., HTTP and XML, so there is
a concern even within these communities that text is not always appropriate.
Moreover, consider where these encodings are used. The textual encoding of control information--signalling--makes sense for protocols whose main purpose is the transmission of truly human-readable textual content, such as email or web pages, but not for pure signalling applications, such as a control protocol for voice communication, where the encoding is rarely encountered by humans. This is a good place to mention the encodings used by H.248 as they relate to H.323 and SIP. Most protocols use either a text or binary encoding--one or the other. However, H.248 (also known as Megaco) uses both--there are text and binary versions of the same messages. Eliminating any differences between protocols like this would then seem like the ideal situation to finally determine which was better, text or binary. Indeed, many SIP and text-encoding proponents cite anecdotal evidence that the binary encoding of H.248 is about the same size and takes about the same amount of time to encode and decode as the text encoding. Some even say that the binary encoding is larger and slower than the text encoding, and a study published on erlang.org seems to bear this out. However, more recent studies on asn1.org completely disprove these assertions. It is important to note that none of these studies purport to prove one way or the other whether binary or text encoding is inherently faster or smaller. All that can be said for certain is that, for the particular H.248 test suite they used, the fastest binary codecs are significantly faster than the fastest text codecs. To think that text is unquestionably faster than binary is now an indefensible, most likely uninformed position. Indeed, until someone can present results to the contrary, the "race" is clearly being won by binary. Regarding the size of H.248 messages, as the study on erlang.org says, "there are no significant differences in message sizes" between the binary and text encodings. This would seem to be an indictment against binary encoding (and therefore H.323) because it is generally assumed that binary is always smaller than text. However, consider that H.248 uses the ASN.1 Basic Encoding Rules, or BER, the very first and least efficient of several encoding rules defined for ASN.1, while H.323 uses the Packed Encoding Rules, or PER, which are advanced, very efficient encoding rules. In fact, the erlang.org study goes on to say, "the ASN.1 PER format is much more compact than all the other alternatives." When people say bad things about the H.248 binary encoding, remember that H.323 uses a completely different encoding. H.323 uses PER to generate much smaller encodings that also take less time to encode and decode than H.248. Luckily, you can check this out because those studies also used PER in place of BER, although H.248 unfortunately dictates BER and not PER. You can see how a different encoding rule effects performance. | SIP messages are encoded in ASCII text format,
suitable for humans to read. As a consequence,
the messages are large and less suitable
for networks where bandwidth, delay, and/or processing
are a concern.
Some argue that message size is not so important because bandwidth is
increasing. However, it is a problem because some SIP messages are
getting so large that they are reaching the MTU (maximum transmission unit) of
the network, risking router fragmentation. As a direct result, it has been at least suggested within the
SIP community that UDP be deprecated. TCP would be used instead.
Now, however, the scheme is to use UDP or TCP on a message-by-message basis depending
on the size of the message.
There have been several proposals, i.e., within both the 3GPP and the IETF, to perform some type of compression on the messages. This demonstrates that there are inherent problems with using ASCII text for communication systems where one or a combination of bandwidth, delay, and processing are a consideration. Even if these schemes achieve their compression goals, the resulting implementations unfortunately have a larger footprint, require more processing, and increase the complexity of the overall encoding scheme. |
| Media Transport | RTP/RTCP | RTP/RTCP |
| Extensibility - Vendor Specific |
H.323 is extended with non-standard features in such a way as to avoid conflicts between vendors. | SIP is extended by adding new header lines that may be used by different vendors to serve different purposes, thus risking interoperability problems. The risk is small, but this problem has already been seen in the real world with similar extension schemes. |
| Extensibility - Standard |
H.323 is extended by the standards community to add new features to H.323 in such a way as to not impact existing features. However, new revisions of H.323 are published periodically, which introduce new functionality that is mandatory, yet done in such a way as to preserve backward compatibility. | SIP is extended by the standards community to add new features to SIP in such a way as to not impact existing features. However, new revisions of SIP are potentially not backward compatible. In addition, several extensions are "mandatory" in some implementations, which cause interoperability problems. |
| Scalability - Load Balancing |
H.323 has the ability to load balance endpoints across a number of alternate gatekeepers in order to scale a local point of presence. In addition, endpoints report their available and total capacity so that calls going to a set of gateways, for example, may be best distributed across those gateways. | SIP has no notion of load balancing. SIP currently relies mostly on DNS SRV for this. In the future, it may rely on HTTP load balancing, presumably modified to recognize SIP headers. However, when trying to build a large service-provider network, an immediate issue that arises is one wherein the ports on the gateway reach 100% utilization. With SIP, there is no way of detecting this problem. As a result, calls simply fail. |
| Scalability - Call Signaling |
When an H.323 gatekeeper is used, it may simply provide address resolution through one RAS message exchange, or it may route all call signaling traffic. In large networks, the direct call model may be used so that endpoints connect directly to one another. | When using a SIP proxy to, for example, perform address resolution for the SIP device, the proxy is required to handle at least 3 full message exchanges for every call. |
| Scalability - Statelessness |
An H.323 gatekeeper can be stateless using the direct call model. | A SIP proxy can be stateless if it does not fork, use TCP, or use multicast. |
| Scalability - Address Resolution |
H.323 defines an interface between the endpoint and gatekeeper for address resolution using ARQ or LRQ. The H.323 gatekeeper may use any number of protocols to discover the destination address of the callee, including LRQs to other gatekeepers, Annex G/H.225.0, TRIP, ENUM, and/or DNS. The endpoint does not have to be concerned with the mechanics of this process, and the processing requirements for address resolution placed on the gatekeeper by H.323 are for just a single message exchange. Although out of scope of H.323, an H.323 endpoint may perform its own address resolution using ENUM and/or DNS and then place a direct call to the resolved address or provide the resolved address to the gatekeeper as an "alias". | While SIP has no address-resolution protocol, per se, a SIP user agent may route its INVITE message through a proxy or redirect server in order to resolve addresses. The SIP proxy may use various protocols to discover the destination address of the callee, including TRIP, ENUM, and/or DNS. The endpoint does not have to be concerned with the mechanics of this process. Unfortunately, the processing requirements placed on the SIP proxy are higher than with H.323 because at least 3 message exchanges must take place between the SIP device, SIP proxy, and the next hop. Although out of scope of SIP, a SIP user agent may perform its own address resolution using ENUM and/or DNS and then place a direct call to the resolved address or through a proxy. |
| Addressing | Flexible addressing mechanisms, including
URLs and E.164 numbers.
H.323 supports these aliases:
| SIP only understands URL-style addresses. |
| Billing | Even with H.323's direct call model, the ability to successfully bill for the call is not lost because the endpoint reports to the gatekeeper the beginning and end time of the call via the RAS protocol. | If the SIP proxy wants to collect billing information, it has no choice but to stay in the call signaling path for the entire duration of the call so that it can detect when the call completes. Even then, the statistics are skewed because the call signaling may have been delayed. |
| Call Setup | A call can be established in as few as 1.5 round trips.
Setup ->
<- Connect Ack -> However, here is the typical message exchange with intermediate response and pre-call audio cut-through. Cut-through is accomplished in 1 round trip and call setup requires 5 messages. Setup(mediaWaitForConnect=FALSE) -> <- Call Proceeding <= audio cut-through Ack -> ... <- Connect Ack -> Originally, H.323 required several messages for call setup and the use of a reliable channel, e.g., TCP. As a result, call setup took much longer than the scenarios described here. Virtually all implementations now use the Fast Connect method introduced in H.323v2, which greatly reduces the call setup delay, but few use H.323 Annex E, which allows the use of an unreliable channel, e.g., UDP, which reduces call setup to the scenarios described here. |
A call can be established in as few as 1.5 round trips.
INVITE ->
<- 200 OK Ack -> However, here is the typical message exchange with intermediate response and pre-call audio cut-through. Cut-through is accomplished in 2 round trips and call setup requires 6 messages. INVITE -> <- 183 Proceeding PRACK -> <= audio cut-through <- 200 PRACK ... <- 200 OK Ack -> |
| Capability Negotiation | H.323 entities may exchange capabilities and negotiate which channels to open, including audio, video, and data channels. Individual channels may be opened and closed during the call without disrupting the other channels. | SIP entities have no means of exchanging capabilities--they can only propose media channels, and the other entity is limited to that proposed set of channels. It has been proposed that SIP entities could simply use re-INVITE procedures to negotiate capabilities. However, there are a number of problems with this including the potential to lose continuity of speech and the potential that the newly proposed capabilities are not supported at the other end. Most importantly, this does not allow the two ends to inform one another of their capabilities. It is a hit-or-miss procedure that leads to suboptimal performance (extended call setup time) and operation between the two entities. |
| Call Forking | H.323 gatekeeper can control the call signaling and may fork the call to any number of devices simultaneously. | SIP proxies can control the call signaling and may fork the call to any number of devices simultaneously. |
| PSTN Interworking | H.323 borrows from traditional PSTN protocols, e.g., Q.931, and is therefore well suited for PSTN integration. However, H.323 does not employ the PSTN's circuit-switched technology--like SIP, H.323 is completely packet-switched. How Media Gateway Controllers fit into the overall H.323 architecture is well-defined within the standard. | SIP has no commonality with the PSTN and such signaling must be "shoe-horned" into SIP. SIP has no architecture that describes the decomposition of the gateway into the Media Gateway Controller and the Media Gateways. |
| Services | Services may be provided to the endpoint through a web-browser interface using HTTP or a feature server using Megaco/H.248. In addition, services may be provided to an endpoint as it places a call, as a call arrives, or during the middle of a call by a gatekeeper or other entity that routes the call signaling. As a result, H.323 is better suited to providing new services. | SIP devices can only receive service from a SIP proxy as the endpoint places a call, as a call arrives, or during the middle of a call. There is no defined way within SIP of providing services via a web browser or a feature server. Although, as with H.323, one may provide ad-hoc services through other means, such as XML, SOAP, or CPL. |
| Video and Data Conferencing | H.323 fully supports video and data conferencing. Procedures are in place to provide control for the conference as well as lip synchronization of audio and video streams. | SIP has limited support for video and no support for data conferencing protocols like T.120. SIP has no protocol to control the conference and there is no mechanism within SIP for lip synchronization. |
| Administrative Requirements | H.323 does not require a gatekeeper. A call can be made directly between two endpoints. | SIP does not require a proxy. A call can be made directly between two user agents. |
| Codecs | H.323 supports any codec, standardized or proprietary, not just ITU-T codecs. There have been codepoints for MPEG and GSM, which are not ITU-T codecs, in H.323 for a long time; many vendors support proprietary codecs through ASN.1 NonStandardParameters, which is equivalent to SIP's "privately-named codec by mutual agreement"; and any codec can be signaled via the GenericCapability feature that was added in H.323v3. Payload types can be specified statically or dynamically. | SIP supports any IANA-registered codec (as a legacy feature) or other codec whose name is mutually agreed upon. Payload types can be specified statically or dynamically. |
| Firewall support | Provided by H.323 proxy, an H.323/H.323 signaling gateway. | Provided by SIP proxy. |
| Transport protocol | Reliable or unreliable, e.g., TCP or UDP. Most H.323 entities use a reliable transport for signaling. | Reliable or unreliable, e.g., TCP or UDP. Most SIP entities use an unreliable transport for signaling. |
| Loop Detection | Yes, routing gatekeepers can detect loops by looking at the CallIdentifier and destinationAddress fields in call-processing messages. If the combination of these matches an existing call, it is a loop. | Yes, the SIP message Via header facilitates this. However, there has been talk about deprecating Via as a means of loop detection due to its complexity. Instead, the Max-Forwards header seems to be the prefered method of limiting hops and therefore loops. |
| Multicast Signaling | Yes, location requests (LRQ) and auto gatekeeper discovery (GRQ). | Yes, e.g., through group INVITEs. |
| Third-party Call Control | Yes, through third-party pause and re-routing which is defined within H.323. More sophisticated control is defined by the related H.450.x series of standards. | Yes, through SIP as described in separate Internet Drafts. |
| Minimum Ports for VoIP Call | 3 (Call signaling, RTP, and RTCP.) | 3 (SIP, RTP, and RTCP.) |
| Conferencing Entity | Yes, an MC is required for this, but it could be co-located in a participating endpoint, or all endpoints could contain an MC. What distinguishes H.323 is not that it requires yet another onerous physical entity for conferencing (it does not) but that it just has a name for this functionality, an "MC," and that it provides a flexible means of implementing that functionality. | No; however, SIP user agents perform conferencing themselves. |
| Original Title | "VISUAL TELEPHONE SYSTEMS AND EQUIPMENT FOR
LOCAL AREA NETWORKS WHICH PROVIDE A NON-GUARANTEED QUALITY OF SERVICE"
It is now, "Packet-based multimedia communications systems."
Despite the word, "VISUAL," in the original title, H.323 has never described just a videoconferencing solution--support for video and data has always been optional. And the reference to LANs may be misleading because H.323 was intended from the start to support simple and "complex topologies" and not just single-segment networks, which "LOCAL AREA NETWORKS" may imply. |
"Application-level protocol for inviting
users to multimedia conferences [emphasis ours]"
It is now, "SIP: Session Initiation Protocol."
Note that the "multimedia conferences" referred to in the original title are loosely coupled multicast conferences, Ã la MBone. This is because SIP was intended to be just a point-to-point version of SAP and not the "carrier-class solution addressing a wide area" that many would have you believe. |
| Lineage | H.323 is based on H.324, not H.320.
However, H.324 was designed to be a better H.320.
|
SIP is frequently allied with the Internet and the World Wide Web by way of HTTP.
|
| Open-source projects | Yes, e.g., OpenH323. | Yes, e.g., Vovida.org. |
| Media Topology | Unicast, multicast, star, and centralized. | Unicast, multicast, star, and centralized. |
| Authentication | Yes, via H.235. | Yes, via HTTP (Digest and Basic), SSL, PGP, S/MIME, or various other means. |
| Encryption | Yes, via H.235. H.323, via H.235, can also use SSL for transport-layer security. | Yes, via SSL, PGP, S/MIME, or various other means. |
| DTMF Carriage | Three ways, with the alphanumeric choice of the H.245 UserInputIndication message being the baseline carriage common to all H.323 endpoints. | Three ways. There is no baseline carriage, which presents issues of interoperability. |
| Standards Documents for Ostensibly Equivalent Functionality Standards that are common to both H.323 and SIP, e.g., RFC 1889, are not shown. |
Core
Approved ITU-T Recommendations.
Optional
Approved ITU-T Recommendations.
|
Core
Approved IETF RFCs.
Optional
Approved IETF RFCs, papers, current and elapsed IETF IDs, and other works in progress.
We know, we know! We shouldn't list all of these documents because it may look unfair to SIP, but this is actually a problem with SIP--how does one know which documents are merely interesting, required, optional, or even very important yet not quite normative?
|
SIP Methods
SIP requests are the codes used by Session Initiation Protocol for communication. To complement them there are SIP Responses, which generally indicate whether this request succeeded or failed, and in the latter case, why it failed.
| Request name | Description | Defined in |
|---|---|---|
| INVITE | Indicates a client is being invited to participate in a call session. | RFC 3261 |
| ACK | Confirms that the client has received a final response to an INVITE request. | RFC 3261 |
| BYE | Terminates a call and can be sent by either the caller or the callee. | RFC 3261 |
| CANCEL | Cancels any pending request. | RFC 3261 |
| OPTIONS | Queries the capabilities of servers. | RFC 3261 |
| REGISTER | Registers the address listed in the To header field with a SIP server. | RFC 3261 |
| PRACK | Provisional acknowledgement. | RFC 3262 |
| SUBSCRIBE | Subscribes for an Event of Notification from the Notifier. | RFC 3265 |
| NOTIFY | Notify the subscriber of a new Event. | RFC 3265 |
| PUBLISH | Publishes an event to the Server. | RFC 3903 |
| INFO | Sends mid-session information that does not modify the session state. | RFC 6086 |
| REFER | Asks recipient to issue SIP request (call transfer.) | RFC 3515 |
| MESSAGE | Transports instant messages using SIP. | RFC 3428 |
| UPDATE | Modifies the state of a session without changing the state of the dialog. | RFC 3311 |
Make SIP Technology Easy
For all SIP professionals and telecom engineers. Blog is specially for all telecom VOIP architects working in telecom field..please stay tuned
The Session Initiation Protocol (SIP) is an IETF-defined signaling protocol widely used for controlling communication sessions such as voice and video calls over Internet Protocol (IP). The protocol can be used for creating, modifying and terminating two-party (unicast) or multiparty (multicast) sessions. Sessions may consist of one or several media streams.
Other SIP applications include video conferencing, streaming multimedia distribution, instant messaging, presence information, file transfer and online games[citation needed].
The SIP protocol is an Application Layer protocol designed to be independent of the underlying Transport Layer; it can run on Transmission Control Protocol (TCP), User Datagram Protocol (UDP), or Stream Control Transmission Protocol (SCTP).It is a text-based protocol, incorporating many elements of the Hypertext Transfer Protocol (HTTP) and the Simple Mail Transfer Protocol (SMTP).
A SIP phone is a SIP user agent that provides the traditional call functions of a telephone, such as dial, answer, reject, hold/unhold, and call transfer.[8][9] SIP phones may be implemented as a hardware device or as a softphone. As vendors increasingly implement SIP as a standard telephony platform, often driven by 4G efforts, the distinction between hardware-based and software-based SIP phones is being blurred and SIP elements are implemented in the basic firmware functions of many IP-capable devices. Examples are devices from Nokia and Research in Motion.[10]
In SIP, as in HTTP, the user agent may identify itself using a message header field 'User-Agent', containing a text description of the software/hardware/product involved. The User-Agent field is sent in request messages, which means that the receiving SIP server can see this information. SIP network elements sometimes store this information,[11] and it can be useful in diagnosing SIP compatibility problems.
SIP registrars are logical elements, and are commonly co-located with SIP proxies. But it is also possible and often good for network scalability to place this location service with a redirect server.
The Session Initiation Protocol (SIP) is an IETF-defined signaling protocol widely used for controlling communication sessions such as voice and video calls over Internet Protocol (IP). The protocol can be used for creating, modifying and terminating two-party (unicast) or multiparty (multicast) sessions. Sessions may consist of one or several media streams.
Other SIP applications include video conferencing, streaming multimedia distribution, instant messaging, presence information, file transfer and online games[citation needed].
The SIP protocol is an Application Layer protocol designed to be independent of the underlying Transport Layer; it can run on Transmission Control Protocol (TCP), User Datagram Protocol (UDP), or Stream Control Transmission Protocol (SCTP).It is a text-based protocol, incorporating many elements of the Hypertext Transfer Protocol (HTTP) and the Simple Mail Transfer Protocol (SMTP).
Network elements
SIP also defines server network elements. Although two SIP endpoints can communicate without any intervening SIP infrastructure, which is why the protocol is described as peer-to-peer, this approach is often impractical for a public service. RFC 3261 defines these server elements.User Agent
A SIP user agent (UA) is a logical network end-point used to create or receive SIP messages and thereby manage a SIP session. A SIP UA can perform the role of a User Agent Client (UAC), which sends SIP requests, and the User Agent Server (UAS), which receives the requests and returns a SIP response. These roles of UAC and UAS only last for the duration of a SIP transaction.[7]A SIP phone is a SIP user agent that provides the traditional call functions of a telephone, such as dial, answer, reject, hold/unhold, and call transfer.[8][9] SIP phones may be implemented as a hardware device or as a softphone. As vendors increasingly implement SIP as a standard telephony platform, often driven by 4G efforts, the distinction between hardware-based and software-based SIP phones is being blurred and SIP elements are implemented in the basic firmware functions of many IP-capable devices. Examples are devices from Nokia and Research in Motion.[10]
In SIP, as in HTTP, the user agent may identify itself using a message header field 'User-Agent', containing a text description of the software/hardware/product involved. The User-Agent field is sent in request messages, which means that the receiving SIP server can see this information. SIP network elements sometimes store this information,[11] and it can be useful in diagnosing SIP compatibility problems.
Proxy server
An intermediary entity that acts as both a server (UAS) and a client (UAC) for the purpose of making requests on behalf of other clients. A proxy server primarily plays the role of routing, which means its job is to ensure that a request is sent to another entity "closer" to the targeted user. Proxies are also useful for enforcing policy (for example, making sure a user is allowed to make a call). A proxy interprets, and, if necessary, rewrites specific parts of a request message before forwarding it.Registrar
A server that accepts REGISTER requests and places the information it receives in those requests into the location service for the domain it handles which registers one or more IP addresses to a certain SIP URI, indicated by the sip: scheme, although other protocol schemes are possible (such as tel:). More than one user agent can register at the same URI, with the result that all registered user agents will receive a call to the SIP URI.SIP registrars are logical elements, and are commonly co-located with SIP proxies. But it is also possible and often good for network scalability to place this location service with a redirect server.
Redirect server
A user agent server that generates 3xx (Redirection) responses to requests it receives, directing the client to contact an alternate set of URIs. The redirect server allows proxy servers to direct SIP session invitations to external domains.Session border controller
Session border controllers Serve as middle boxes between UA and SIP server for various types of functions, including network topology hiding, and assistance in NAT traversal.Gateway
Gateways can be used to interface a SIP network to other networks, such as the public switched telephone network, which use different protocols or technologies.
