sip and ip protocol...


IP (Internet Protocol) technology has been incorporated into many more devices than computers and network switches. For example, SIP/VoIP Telephone or Video Systems, and Mobile Devices. We provide both SIP and IP solutions, so if you think we can help, call us on 01983 217500

SIP/VoIP phones are very reliable - but only if the VoIP packets are being sent at 64kbps over an IP stream that’s dedicated for voice calls. As the SIP reuses the HTTP headers and also sets up a relative session during your conversation. The result of which sort of mimics the traditional PSTN network, in that it works to assure that all the packets travel the same paths in order to enhance the quality of the voice conversation via reduced latency.

Internet VoIP Phones are unreliable - because their VoIP packets are sent over the Public Internet via multiple networks, and IP makes no guarantees about the delivery time of its packets. So your calls either drop, fail to transfer internally or you sound like you’re talking in an echo chamber, because none, some, or all of the following have happened:

 – out of order (packet A may be sent before packet B, but B can arrive before A) 

 – duplicate arrival 

 – lost or dropped/discarded 

In terms of reliability the only thing IP does is ensure the IP packet's header is error-free through the use of a checksum. This has the side-effect of discarding packets with bad headers on the spot, and with no required notification to either end, though an Internet Control Message Protocol (ICMP) message may be sent.

To address any of these reliability issues, an upper layer protocol must handle it. For example, to ensure in-order delivery the upper layer may have to cache data until it can be passed up in order.

The primary reason for the lack of reliability is to reduce the complexity of routers. While this does give routers carte blanche to do as they please with packets, anything less than best effort yields a poorer experience for the user. So, even though no guarantees are made, the better the effort made by the network, the better the experience for the user.

Encapsulation of user data in a UDP datagram inside an IP packet

Encapsulation of user data in a UDP datagram inside an IP packet.

Data from an upper layer protocol is encapsulated inside one or more packets/datagrams (the terms are basically synonymous in IP). No circuit setup is needed before a host tries to send packets to a host it has previously not communicated with (this is the point of a packet-switched network). This is quite unlike Public Switched Telephone Networks that require the setup of a circuit before a phone call may go through.

Because of the abstraction provided by encapsulation, IP can be used over a heterogeneous network (i.e., a network connecting two devices can be any mix of Ethernet, ATM, FDDI, Wi-fi, Token ring, etc.) and it makes no difference to the upper layer protocols.

All the data link layers can (and do) have their own set of addressing (or possibly the complete lack of it) and the need to resolve IP addresses to data link addresses is needed. This resolving is addressed by the Address Resolution Protocol (ARP).

Perhaps the most complex aspects of IP are IP addressing and routing. Addressing refers to how end hosts become assigned IP addresses and how sub networks of IP host addresses are divided and grouped together. IP routing is performed by all hosts, but most importantly by internetwork routers, which typically use either interior gateway protocols (IGPs) or external gateway protocols (EGPs) to help make IP datagram forwarding decisions across IP connected networks.

IP is the common element found in today's public Internet. The current and most popular network layer protocol in use today is IPv4; this version of the protocol is assigned version 4. IPv4 was adopted by the United States Department of Defense as MIL-STD-1778.

IPv6 is the proposed successor to IPv4 whose most prominent change is the addressing. IPv4 uses 32-bit addresses (~4 billion addresses) while IPv6 uses 128-bit addresses (~3.4×1038 addresses)

Versions 0 through 3 were either reserved or unused; version 5 was used for an experimental stream protocol. Other version numbers have been assigned, usually for experimental protocols, but have not been widely used.

01983 217500