Thus, SIP is quite similar to HTTP. The first line is the request line, which contains information regarding the type of request (GET in HTTP and INVITE in SIP for these examples) and the intended address, while subsequent lines are headers with additional information. Naturally, responses in SIP also look very similar to HTTP responses. The idea is to use the structure of one of the most popular Internet protocols and make it easier for software developers and network managers to work with SIP.
These attempts to make SIP as easy as HTTP worked out to some extent, but the requirements of SIP addresses are more complex than HTTP, so the protocol is more complex. For example, it is a basic requirement in SIP to be able to have 2-way symmetric communication, whereas a typical HTTP scenario would be a client making requests to a server and the server sending a response. Even without prior HTTP knowledge, learning this message structure is a very easy task.
For those who are wondering, the SIP example above is the first packet one might send when calling from a SIP phone to Ars Technica’s Deputy Editor, Jon Stokes. I will refrain from going into the technical details of the message contents at this time, as this is a subject for a separate article.
Reuse, and keeping it simple ************** (The role of a signaling protocol is to define the way these messages are structured and the rules that let us start, configure, and end conversation.
Another important factor in SIP’s design was the decision to reuse other existing Internet standards as much as possible. Address location uses DNS, user authentication uses HTTP digest authentication, setting the call media streams uses the Session Description Protocol (SDP), encryption uses TLS and, when applicable, users send each other XML information. This integration further helped establish SIP as part of the Internet protocol world, and vendors could reuse existing implementations in their SIP applications. On the other hand, in some cases the IETF had to make additional definitions in other protocols in order to serve SIP needs.
Keeping the complexity of the servers, especially the proxies, along the call path as minimal as possible is also an emphasis in SIP’s design. SIP Proxies route the messages between the calling parties. The proxies defined in the standard are not aware of the call state, but rather operate on the transaction level and may also be stateless. This helps with scalability, because fewer devices can serve more calls. To do that, the protocol itself was separated to several distinct layers, a common practice programmers use to break down a complex system. This design helps to further simplify SIP and make it easier to implement. At times, keeping this minimal state forced some limitations (and later, some changes in the protocol), but these byproducts were kept to a minimum.
Finally, and perhaps most importantly, SIP was not built solely as a replacement for the telephone system. It allows extensions, and it relies on them to provide additional services beyond just simple calls. For example, you can use SIP to maintain user status information in an IM client as well as to set up IM sessions. Another extension enables transferring a call to a third party, something that was simply not defined by the basic SIP specification. This is possible thanks to the fact that SIP provides the necessary basic constructs while limiting those constructs only when necessary. SIP defines the concept of “dialog” which is a 2-way communication, but does not limit dialogs to calls. Two-way communication also includes setting your IM status and receiving your IM friends ’updates. Extensions can also easily define new request or response types and new headers when needed.
(************************************** Page: (1) ******************************************* (2) **************************Next →
GIPHY App Key not set. Please check settings