CEM KAYA

CLI for Caller ID

The caller ID information is passed through from the ISDN-to-SIP by copying the number in the Calling Party Number information element (IE) in an ISDN Setup message into the Calling Number field of the SIP Remote-Party-ID and From headers.

However, for added privacy, the SIP: CLI for Caller ID When Privacy Exists feature introduces CLI to completely remove the Calling Number and Display Name from an outgoing message’s From header if presentation is prohibited. This prohibits sending the SIP Remote Party ID header, because the Cisco gateway does not send SIP Remote-Party ID headers without both a Display Name and Calling Number.

Presentation Indicator : Presentation Allowed

From: “User1” <sip:5550100@10.0.0.0>;tag=1

Remote-Party-ID: “User1”<sip:5550100@10.0.0.0>;party=calling;privacy=off

Presentation Indicator : Presentation Prohibited

From: “User1” <sip:5550100@10.0.0.0>;tag=1

Remote-Party-ID: “User1”<sip:5550100@10.0.0.0>;party=calling;privacy=full

Remote-Party-Id

This header was defined in a failed RFC : http://tools.ietf.org/html/draft-ietf-sip-privacy-00 . Although this header is supported by SIP devices and SIP PBXs, this was never accepted […]

VOIP|

EIGRP

Enhanced Interior Gateway Protocol (EIGRP) is a proprietary hybrid routing protocol developed by Cisco Systems. EIGRP uses the same distance vector algorithm and distance information as IGRP. However, as its name implies, EIGRP has been enhanced in convergence properties and operating efficiency over IGRP. Principally, EIGRP has been enhanced to use more advanced features to avoid routing loops and to speed convergence time. In addition, EIGRP transmits the subnet mask for each routing entry, enabling EIGRP to support features such as VLSM and route summarization.

EIGRP Features

EIGRP provides advanced features over its predecessors IGRP and RIP:

Increased network width— With IP RIP, the largest possible width of your network is 15 hops. When IP EIGRP is enabled, the largest possible width is 224 hops.
Fast convergence— EIGRP uses an algorithm called the Diffusing Update Algorithm (DUAL). This algorithm guarantees loop-free operation at every […]

NETWORK|

IGRP

IGRP – Interior Gateway Routing Protocol

The Interior Gateway Routing Protocol (IGRP) is an advanced distance vector routing protocol. Because it is a Cisco-developed routing protocol, only Cisco devices can utilize this protocol for routing purposes. Like RIP, it is a classful protocol; meaning that it does not send the subnet mask with routing updates. So, it cannot support VLSMs.

A router running IGRP sends an update broadcast every 90 seconds, by default. When an update from the originating router is not received within three update periods (270 seconds), it declares a route invalid. After seven update periods (630 seconds), which include the three update periods, the router removes the route from the routing table.

IGRP advertises three types of routes:

Interior— Routes between subnets in the network attached to a router interface.
System— Routes to networks within an autonomous system. The router derives system routes from […]

NETWORK|

OSPF

The OSPF (Open Shortest Path First) protocol is one of a family of IP Routing protocols, and is an Interior Gateway Protocol (IGP) for the Internet, used to distribute IP routing information throughout a single Autonomous System (AS) in an IP network.

The OSPF protocol is a link-state routing protocol, which means that the routers exchange topology information with their nearest neighbors. The topology information is flooded throughout the AS, so that every router within the AS has a complete picture of the topology of the AS. This picture is then used to calculate end-to-end paths through the AS, normally using a variant of the Dijkstra algorithm. Therefore, in a link-state routing protocol, the next hop address to which data is forwarded is determined by choosing the best end-to-end path to the eventual destination.

Each OSPF router distributes information about its local […]

NETWORK|

Spanning Tree Protocol

Spanning Tree Protocol – STP

The Spanning Tree Protocol is a link management protocol that is designed to support redundant links while at the same time preventing switching loops in the network. It is quite useful and should be enabled on the switch interfaces.
STP has high convergence time; it can take up to one minute to converge and provide redundancy. A newer development is implemented to the STP protocol, called the Rapid Spanning Tree Protocol (RSTP). The latter retains all the tasks of STP whilst minimizing convergence time significantly.

Spanning Tree Protocol

The root bridge needs to be elected. Two fields combined together identify the root bridge: MAC address and Priority value. Without manual configuration all switches have the same priority therefore it is up to the MAC address to decide upon […]

NETWORK|

VoIP packet format with voice payload and headers

A compressed voice frame is required to be packetized with Real-Time Transport Protocol (RTP), User Datagram Protocol (UDP), and IP headers and then encapsulated with network interface headers.

The RTP header is 12 bytes. Voice is sensitive to delays. RTP helps proper end-to-end delivery of real-time voice traffic. RTP header compression reduces the number of bytes, but header compression is not considered in this topic. Details on RTP are given in RFC3550.

Compressed payload, RTP, UDP, and IP header combinations are described as VoIP packets.

VoIP header = (IP + UDP + RTP) = 40 bytes in IPv4 and 60 bytes in IP version 6 (IPv6)
VoIP packet = (VoIP header + voice payload)

Physical network […]

SIP, VOIP|

Voice Troubleshooting in a Cisco Router

A voice call over a packet network is segmented into discrete call legs. A call leg is a logical connection between two voice gateways or between a gateway and an IP telephony device. Troubleshooting, debugging and sniffing should focus first on each leg independently and then on the VoIP call as a whole. You can isolate where a problem is occurring by determining which dial peer or call leg is having the problem.

You need to understand the call path through the router in order to determine where a problem is occurring.

• Call control application programming interface (CCAPI)—Three clients make use of the CCAPI: command-line interface (CLI), Simple Network Management Protocol (SNMP) agent and Session Application. The CCAPI main functions are:
– Identify the call legs (Which dial peer is it? Where did it come from?).
– Decide which session application takes the call (Who handles it?).
– Invoke the packet handler.
– Conference the […]

CISCO, SIP, VOIP|

One-two Way Audio Problem in SIP

During the initial SIP offer/answer exchange, both the originating and terminating SIP user agents (UAs) specify in the SDP payload the desired IP address and port combination for the caller and callee to receive the associated media stream and to properly direct the signaling stream. SIP UAs within the enclave may use private addressing for topology hiding reasons. A problem occurs when private addressing is used within the SDP payload since the private address is not resolvable from the WAN side of the NAT.

A traditional NAT device will change the IP source address and/or port combination at packet header level, but not the IP address within the SDP payload. Consequently, the callee, or UA in the remote enclave, will not have the correct IP address to respond to from a signaling perspective and the call setup will fail. Even if the call is established from a signaling perspective, […]

SIP, VOIP|

Early Media and Ringing Tone Generation in SIP

The concept of “early media” can sometimes confuse . In RFC 3960 defines it as:

   Early media refers to media (e.g., audio and video) that is exchanged
   before a particular session is accepted by the called user.  Within a
   dialog, early media occurs from the moment the initial INVITE is sent
   until the User Agent Server (UAS) generates a final response.  It may
   be unidirectional or bidirectional, and can be generated by the
   caller, the callee, or both.

   An UAC should develop its local policy regarding

   local ringing generation.  For example, a POTS ("Plain Old Telephone

   Service")-like SIP User Agent (UA) could implement the following

   [...]

SIP, VOIP|

Codecs and Required Bandwidth

The required bandwidth for a single call, in one direction, is 64 kbps. As the G.711 codec samples 20 ms of voice per packet, 50 such packets need to be transmitted per second. Each packet contains 160 voice samples, which gives 8000 samples per second. Each packet is sent in one Ethernet frame. With every packet of size 160 bytes, headers of additional protocol layers are added. These headers include RTP + UDP + IP + Ethernet, with a preamble of sizes, 12 + 8 + 20 + 26, respectively. Therefore, a total of 226 bytes, or 1808 bits, must be transmitted 50 times per second, or 90.4 kbps, in one direction. For both directions, the required bandwidth for a single call is 100 pps or 180.8 kbps, assuming a symmetric flow.

Waveform codecs:– Directly encode speech in an efficient way […]

SIP, VOIP|

Blog

Remote-Party-Id

EIGRP

EIGRP Features

IGRP – Interior Gateway Routing Protocol

OSPF

Spanning Tree Protocol – STP

VoIP packet format with voice payload and headers

Early Media and Ringing Tone Generation in SIP

Codecs and Required Bandwidth