IP Telephony Technical Notes

Version:2.12 Date:14/5/2007 Author: Scott Hayman ACA-ACS-ACI

IPL Communications Web: http://www.ipl.com.au/iplcommunication Contents Technical Notes on IP Telephony Please note the reader should have a solid understanding of Bits/Bytes conversion and have a very sound understanding of networking principles, terminology and technologies. 1, Assess the Ability of Your Network to Handle VoIP by NetPredict 2, General VoIP Protocol Information 3, VoIP Bandwidth calculations 4, VoIP through Firewalls 5, Standard IPO/IPNC Ports 6, Quality of Service 7, Class of Service-Type of Service 8, Ensuring Quality of Service over IP by AVAYA 9, Site to Site - MPLS example and configuration 10, IP Phones - VLAN example and configuration 11, TOS, Precedence and DSCP explained 12, Tips from the trenches on VoIP 13, General Network Protocol Information 14, VoIP Mean Opinion Scores 15, Internet throughput description 16, IP Office SCN (Small Community Network) Supported Configurations 17, VLAN Suggestion Diagrams 18, SIP Sample Configurations and Australian Test Results 19, Other Useful SIP related Information Pre Sales Data Collection Sheets 1, 2, 3, 4, Reseller Customer information Voice Related Brief Questions Data Related Brief Questions End user / Reseller confirmation sheet

IPL COMMUNICATION PTY LTD ABN 51 09 4 955 576 146 ORiordan Street, Mascot, NSW, 2020 Tel 1300 304 475 Fax (+61 2) 9667 7191 http://www.ipl.com.au

1, Assess the Ability of Your Network to Handle VoIP by NetPredict Voice over IP (VoIP) has the potential of significant cost savings (e.g., lower toll charges and reduced capital costs) and increased functionality. If you already have a good phone system, any change must result in reduced cost and the quality of the new system must be acceptable. If you convert your phone to VoIP, it might become the most important business application running across your network. If you expect to run long-distance phone calls over your network or internal calls, you should determine ahead of time if your network will provide good voice quality for the remote locations. This paper discusses the methodology that NetPredict uses for such analysis. The focus is on one of the most difficult problems in VoIP applications: effect of network congestion. The users of the capabilities discussed in this paper are enterprises, consultants and system integrators involved in assessment of network performance in support of VoIP implementation. QUALITY INDEX There are two commonly used metrics to express the quality of voice streams. We use both metrics because some vendors report their results in one metric but not the other. The first such metric is the Mean Opinion Score (MOS). Preselected voice samples were recorded and played back to a mixed group of people under controlled conditions. The scores given by the

A MOS of 5 is the quality you hear when you play a CD. It is not attainable through ordinary phones and definitely not achievable for VoIP. A MOS of 4.0 or more is considered toll-quality voice. The metric we prefer is the R-value. It has a better model for predicting the effect of delays and packet losses in the network. Furthermore, it is recommended by the Telecommunications Industry Association; see ref (1). Figure 1 is copied from their document. It shows the colours and wording they use as well as the relationship to the MOS score.

Page 2 of 133

Based on the information in Figure 1, the relationship between R and MOS is almost linear; see Figure 2. On the average, you can assume that a change in MOS of 1 unit corresponds to 21 units of change in R.

EFFECT OF CODECS The following table from a Cisco website shows the performance of a few codecs for Cisco IP phones. A codec is the function that performs coding and decoding of voice data based on algorithms described in G.7nn standards. You may find the values in this table to be different from other documents since there is some variability in the implementation of the standards.

The bit rates in the above table refer to payloads. Since H.323 voice packets contain 58 bytes of headers in addition to the payload, the actual number of bits going across the network is substantially larger than the values in the above table. The following table shows the amount of compression and amount of overhead.

From a cost standpoint, it might seem logical to convert all calls to high compression to save on infrastructure costs. However, there are drawbacks to compression due to reduced quality. Consider a

Page 3 of 133

codec that has a R-value of 76. As you add the effects of delays and packet losses, you will find that it is not easy to achieve good quality. DELAYS It is generally agreed that 150 ms is the maximum desired one-way delay for acceptable two-way communication. Delays above 400 ms result in poor quality because the communication then starts to resemble walkie-talkie. The various codecs have different ability to deal with delays and losses. Figure 3 shows the R-values as a function of delay for various loss rates for G.711. Since this codec has no compression, it represents the best possible quality. The results in Figure 3 are based on the G.711 codec performing packet loss concealment (PLC). If there is no PLC, the curves should be shifted down by R=20. Since that is a reduction of two levels of user satisfaction, it is not an attractive solution. Figure 4 shows the R-values for two other codecs in the case of no packet loss. Notice that there is a knee in the curves at about 175 ms. The region between 175 and 200 ms is where the delay starts to affect the dynamics of the conversation. The steeper slope after 175 ms reflects the rapid degradation of the dynamics of normal conversation with increasing delay.

Page 4 of 133

In normal face-to-face conversation, after one person speaks, there is approximately a 200 ms break, then the other person speaks, followed by another 200 ms break, and so on. When the delay becomes larger, there is loss of synchronization between the speakers. Often, when there is even more delay, one person will start talking before the other person is finished or both people will talk simultaneously.

Page 5 of 133

TRAVEL DELAY Data going through wires and fibers travel at about 2/3 the speed of light. Furthermore, there are additional delays due to various network devices along the path. The time it takes to travel long distances is approximately 17 ms per 1000 miles of air-route distance. This delay includes the 2/3 speed-of-light travel time, the time it takes to go through the various devices along the path, plus 25% extra distance because wires do not go in straight lines. As a result, for a connection between San Francisco and New York, there is a minimum one-way delay of about 40 ms due to travel distance. It may sometimes be more depending on the routes selected by the service provider. There is nothing you can do to reduce this delay. SERIALIZATION DELAY The time it takes to put a data packet onto a link is determined by packet size divided by the capacity of the link. For a packet of 126 bytes and a 144 kb/s link, the delay is 7 ms. If the link is changed to a T1 (1.5 Mb/s), the delay is reduced to 0.7 ms. Thus, the capacity of the link is not necessarily a dominant contributor with respect to delay. However, a low bandwidth link is more sensitive to congestion which may cause substantial queuing delay. JITTER Jitter is a measure of variation in packet interarrival time. You can think of it as an estimate of the standard deviation of the interarrival time. Our software has a formula for the standard definition of jitter; however, we have found it to be of little use. Our approach is to estimate how many packets arrive too late into the jitter buffer. This approach is explained in the next few pages. Most of the jitter originates at the edge, i.e., in the router that is feeding the link between the LAN and the service provider. Delays occur in the router queue due to contention for access to the WAN link. This delay is highly dependent on the amount of traffic through the link. Providing priority to the stream usually reduces queuing delay; adding bandwidth is another solution. The impact of jitter is generally reduced by a jitter buffer at the receiver. This buffer allows the receiver to play the stream in a smooth fashion even if some packets arrive late. Thus, small jitter has no impact on the quality experienced by the end user. However, delays beyond the size of the jitter buffer has the effect of the packet being lost. Thus, a useful jitter measurement must determine the presence of such large delays. The size of the jitter buffer is determined by the implementer of the decoder. It is often a multiple of the packet speech length resulting in the equivalent of 40 to 120 ms delays. The value is usually specified by default; however, in some products it can be changed by the user. Specifying the length of the jitter buffer, and consequently the amount of delay, is fundamentally a trade-off: - A large buffer provides for more packets to be included in reproducing the speech but it adds to the total delay. - A short buffer makes the phone conversation more snappy but it increases the number of packets that are excluded from the generated speech.

Page 6 of 133

PACKET LOSS Packet losses occur mostly in router queues that are temporarily filled due to bursts of congestion. This is normal behaviour. If the size of these bursts is larger than the size of the router queue, some packets will be lost. The amount of loss is typically higher in situations where there are large decelerations in link speed; e.g., 100 Mb/s LAN feeding a 144 kb/s WAN. Most losses occur in the edge routers between the LAN and the WAN. Since packet loss increases when the queue is crowded, the loss for a VoIP stream can be reduced on the expense of other streams by assigning it high priority. If back-to-back packets are lost, it is more difficult for the listener to decipher what is being said. Jonathan Rosenberg of Lucent Technology and Columbia University in G.729 Error Recovery for Internet Telephony presented at the V.O.N. Conference 9/1997 gave the following table showing the relation between R and consecutive packets lost.

Figure 5 plots the values in this table. The plot is almost a straight line. On the average, R=-16 for each additional consecutive loss.

Consider the case of 5% packet loss. Assume that the losses are uniformly distributed. Then, most of the packets are lost one at the time resulting in the following conclusion: R decreases by 13 units 5% of the time. If the packets always are lost in groups of 5, one can make the following statement: R decreases by 78units 5% of the time. As you can see, there is a big difference between these two statements.

Page 7 of 133

PUTTING IT TOGETHER These are the steps we follow to assess the impact of codec, delay and jitter: 1. Codec: Select, or hypothesize, a codec that you will use. This establishes a baseline delay and R-value. Your selection of codec easily accounts for 50% of the degradation in voice quality. If you need best available quality, use G.711. If you are limited by bandwidth, use a compression codec but make sure it has loss concealment. 2. Equipment: Select, or hypothesize, the end-point equipment you will use and determine the size of the jitter buffer. If you do not know this value, assume it to be 60 ms. The highest value you should consider is 150 ms. 3. Locations: Select a few geographic locations you wish to focus on and identify the most likely source(s) of congestion. It is probably the router connecting to your WAN. 4. Travel time: Analyze a TCP stream (e.g., a file transfer) between the selected locations and measure the packet round trip travel time (RTT) between the selected end-points. As an alternative, use ping measurements. Use the smallest RTT, which is an attribute of the network, as opposed to the average value which includes the effect of congestion. Settle for an accuracy of 5%. It is not necessary to seek better than 5% accuracy for long distances since route swapping and other effects are likely to happen from time to time. Dividing the round trip time by 2 to find the one-way delay is sufficient. 5. Jitter: Generate a UDP stream between the selected locations and measure the distribution of the packet interarrival time. Determine the percent delay beyond the jitter buffer. Perform this experiment for representative traffic conditions and preferably with a UDP intensity similar to the voice traffic. 6. Packet loss: Determine the average packet loss for the same UDP stream. Take this measured value and add the packet loss caused by the number of packets that arrive too late for the jitter buffer to get an effective loss rate. 7. Quality: Compute the R-value based on Figure 6. Since the jitter has a statistical distribution, the R-value will have a distribution as well. If the results are unsatisfactory, you need to determine where you can improve and then do the assessment again. Figure 6 is based on the same data as Figure 3. This plot shows the level of user satisfaction for various delay and loss for G.711; i.e., this is the best case scenario. If you use another codec, you need to compare the R-value for your codec to G.711 and then assume there is an equivalent of an extra packet loss of 0.4% for every unit of difference between the two codecs.

Page 8 of 133

EXAMPLE The following is an analysis of a UDP stream generated by Yahoo! Communicator. One person was speaking into a microphone at one computer while another person was collecting data at the receiving computer. The data were travelling less than 100 miles from the source to a central server and back to the receiver. Characterization of Voice Stream The left side of Figure 7 was produced by our NetCalibrator product. It shows the cumulative payload for the outgoing stream. The three gaps are due to silence suppression during breaks in the speech. The plot on the right shows the cumulative distribution of the packet interarrival time for the outgoing stream. It shows that the 126 byte packets are close to uniformly separated by 66 ms; i.e., 15 packets per second. The bit rate was measured to be 16 kb/s. We measured the packet loss to be 6% and the one-way travel time was approximately 1.2 sec which mostly included processing and delay at a central server. Thus, this stream is not good for two-way communication; however, it is interesting for analysis of voice quality. For the purpose of illustration, let us assume that we are dealing with G.723 which has 30 ms for compression/decompression at each end and that we are dealing with a distance equivalent to 50 ms travel time. The resulting total minimum delay is 115 ms and 6% loss. From Figure 4, you can see that G.723 has a shift of R=-15 relative to G.711 and comparing Figures 3 and 4, you can see that this is equivalent to G.711 with 5% packet loss. Thus, the result is that the best you can achieve is the borderline between many users dissatisfied and nearly all users dissatisfied.

Page 9 of 133

Variability of Arriving Stream Figure 8 shows the packets arriving at the destination. This stream had high variability because the packets encountered severe congestion caused by a persistent file transfer through the 144 kb/s link between the service provider and the receiving computer.

To determine the effect of the jitter, let us first add the red horizontal axis shown in Figure 9 with its origin at the delay=115 ms and packet loss=11% point. By combining the information in Figures 8 and 9, you can find the following: R is between 60 and 70 60% of the time -> many user dissatisfied R is between 50 and 60 17% of the time-> nearly all users dissatisfied R is less than 50 23% of the time -> not recommended performance

Page 10 of 133

The previous paragraph assumed a very large (>300 ms) jitter buffer. Assume we knew that the buffer was 100 ms,that would imply that the jitter buffer would discard approximately 25% of the packets. This would result in even worse performance due to high packet loss.

Discouraged by such poor performance, you can turn the problem around and search for the conditions for which acceptable results might be obtained. This can be determined because the jitter in Figure 8 depends on the amount of congestion and the size of the packets in the competing stream. Thus, you can determine how much congestion can be tolerated to achieve a desired performance. For example, you can determine the number of simultaneous voice streams you can tolerate given that you do not accept nearly all users dissatisfied more than (for example) 5% of the time. Another insight you can get from comparing Figures 8 and 9 is the effect of the congestion. In this case, most of the congestion consists of 1518 bytes packets. If one such packet is ahead of a voice packet, the latter will be delayed by 84 ms. If there are two such packets, the delay will be 168 ms, and so forth. If you look carefully, you will see cliffs at 84 ms, 168 ms and 252 ms. Thus, the source of the congestion is now revealed. Based on these observations, you can also determine a solution: Provide high priority to the voice stream at the edge router to make sure no more than one other packet from non-voice streams get ahead of your VoIP stream. However, even if only one large packet gets ahead of a voice packet, the delay is 84 ms which will exceed the stated performance requirement. Thus, it is difficult to achieve good quality for this combination of codec, distance, equipment and bandwidth unless you decide to block all other traffic while talking on VoIP phone.

Page 11 of 133

Another issue is to determine the extent to which the packets are delayed in groups. Figure 10 shows a representative 10 seconds segment of packet interarrival-time (PIT) as a function of frame number. You can see that there are 14 packets with delay less than 150 ms and 7 packets with larger delay. However, there are no two consecutive packets that are highly delayed. This is actually reasonable because if one packet is late, the next packet is likely to come shortly thereafter. The exact nature of the delays depends on the character of the congestion and no general statements can be made without reference to a specific situation.

This illustrates a deficiency in the state-of-the-art in terms of quantifying the impact of bursty congestion The delays in Figure 10 are not random and they are not consecutive; however, there is clearly some clumping (e.g., every other packets are delayed in some instances). To keep the analysis manageable, we simply assume uniform distribution and then add conservatism to the interpretation of the results. Predictive Calculations Figure 11 shows the predicted sources of delay and jitter for the example we have discussed. Our NetPredictor product was used to produce this result. The light grey colour shows the latency in the server, the light blue colour is the time needed for the packet to get onto the 144 kb/s link, the red colour is the variability due to 90% congestion caused by the file transfer, and the yellow colour represents the minimum one-way delay due to the network. The red colour is due to queuing delay in the router. The distance between the two small markers represents the theoretically predicted jitter. We use a queuing model consistent with the recommendations in ref 1. By inspecting Figure 11, you can find where the major delays originate (in this case in the server and the inbound 144 kb/s link) and you can determine if the performance is as expected by comparing with the measured results. When you understand where the delays come from, you can more easily evaluate solutions in an informed manner.

Page 12 of 133

NETPREDICT SOLUTION This paper has outlined the approach NetPredict uses to analyze the quality of voice over IP. We compute R-values based on an industry-standard model using one-way travel delay, packet losses, and codec as inputs to obtain an objective measure of voice quality. Because network traffic always has some degree of variability, a statistical analysis of the data is required. The approach discussed in this paper has been used to predict the quality of hypothesized situations as well as quantifying the quality of existing configurations. Our NetCalibrator and NetPredictor software products facilitate the generation of the key performance numbers. IPL have no connection or affiliation with Net Predict we simply provide this section as it is revellent to VoIP network Design This White Paper can be downloaded in full from http://netpredict.com/pdfs_all/WhitePaper-VoIP.pdf

Page 13 of 133

Technical Notes on IP Telephony Reader needs to have solid understanding of IP Networking and Bytes to Bits Conversion. Knowledge of the networking OSI model and the H323 OSI as well as the concept of encapsulation / de-encapsulation within a data network. These technical notes above are provided to give the end user or reseller an idea of VoIP bandwidth requirements only. There are many more factors that can affect VoIP quality, such as queuing mechanisms, fragmentation, interleaving types, as well as carriers, general networking rules, overall network design, hardware used, end to end delay, packet classification (CoS), IPO Small Community networking traffic and many more. IPL simply provide this information for general use and cannot held responsible for any misinterpretation made within. IPO = AVAYA IP Office IPNC = AVAYA Index Networking cassette 2, General VoIP Protocol Information The VoIP OSI Model Layer Layer Layer Layer Layer Layer 6 5 4 3 2 1 Presentation Session Transport Network Data Link Physical G.711 / G.729 / G.726 / G.723 H.323 / H.323Gateway / SIP / SDP RTP / RTCP / TCP / UDP / RSVP IP / LLQ / IP-Precedence / DiffServ PPP / MLPPP / FR / ATM AAL5 / Ethernet

H323 Protocols Call Control Data Audio Video Audio Video Control RTCP UDP IP H.323 Note: The IPO conforms to H323v2 Standard and as yet does not support SIP H.323, a protocol suite defined by ITU-T, is for voice transmission over internet (Voice over IP or VOIP). In addition to voice applications, H.323 provides mechanisms for video communication and data collaboration, in combination with the ITU-T T.120 series standards. H.323 is one of the major VOIP standards, on a par with Megaco and SIP. Control

H.235

H.225 H.245 (Q.931) TCP

T.120

G.7xx H.26x RTP

RAS (H.225)

Page 14 of 133

H.225: Call Signaling and RAS in H.323 H.225.0, a key protocol in the H.323 VOIP architecture defined by ITU-T,is a standard to cover narrowband visual telephone services defined in H.200/AV.120-Series Recommendations. It specifically deals with those situations where the transmission path includes one or more packet based networks, each of which is configured and managed to provide a non-guaranteed QoS, which is not equivalent to that of N-ISDN, such that additional protection or recovery mechanisms beyond those mandated by Rec. H.320 are necessary in the terminals. H.225.0 describes how audio, video, data and control information on a packet based network can be managed to provide conversational services in H.323 equipment. H.225.0 has two major parts: Call signaling and RAS (Registration, Admission and Status). H.225.0 call control signaling is used to setup connections between H.323 endpoints. This is achieved by exchanging H.225 protocol messages on the call-signaling channel. The call-signaling channel is opened between two H.323 endpoints or between an endpoint and the gatekeeper. The ITU H.225.0 recommendation specifies the use and support of Q.931 signaling messages. A reliable (TCP) call control channel is created across an IP network on TCP port 1720. This port initiates the Q.931 call control messages for the purpose of connecting, maintaining, and disconnecting calls. When a gateway is present in the network zone, H.225.0 call setup messages are exchanged either via Direct Call Signaling or Gatekeeper-Routed Call Signaling (GKRCS). The gatekeeper decides the method chosen during the RAS admission message exchange. If no gatekeeper is present, H.225 messages are exchanged directly between the endpoints. H.225.0/RAS (Registration, Admission and Status) is the protocol between endpoints (terminals and gateways) and gatekeepers. The RAS is used to perform registration, admission control, bandwidth changes, status, and disengage procedures between endpoints and gatekeepers. An RAS channel is used to exchange RAS messages. This signaling channel is opened between an endpoint and a gatekeeper prior to the establishment of any other channels.

Page 15 of 133

H.245: Control Protocol for Multimedia Communication H.245, a control signalling protocol in the H.323 multimedia communication architecture, is for of the exchange of end-to-end H.245 messages between communicating H.323 endpoints/terminals. The H.245 control messages are carried over H.245 control channels. The H.245 control channel is the logical channel 0 and is permanently open, unlike the media channels. The messages carried include messages to exchange capabilities of terminals and to open and close logical channels. After a connection has been set up via the call signalling procedure, the H.245 call control protocol is used to resolve the call media type and establish the media flow, before the call can be established. It also manages the call after it has been established. The steps involved are: Master-slave determination process. It is used to determine the master of the call and is useful for avoiding conflicts during call control operations.. Capability exchange procedure. Each endpoint notifies the other what kind of information it is capable of receiving and transmitting through the receive and transmit capabilities. Logical channel procedures. Used for opening and closing logical channels, which are multiplexed paths between the endpoints used for data transfer. Request mode command. Using this command, at any point during the conference, the receiving endpoint can request for a change in mode of the transmitted information provided the mode is in the transmit capability of the transmitter. Control flow command. This can be used by the receiver to fix an upper limit for the transmitter bit rate on any logical channel. Communication mode messages. Used by the multipoint controller for selecting a common mode of operation in a multipoint conference. Conference request and response messages. Used for controlling a multipoint conference, eg. password requests, conference chair control. Round trip delay commands. Used for measuring the round-trip delay between two endpoints on the control channel. Video fast update command. Used for requesting updates for video frames, in case of data loss. End session command. After this command the endpoints close all logical channels, drop the call and inform the gatekeeper about the end of the call.

Page 16 of 133

RTCP: Real Time Transport Control Protocol (or RTP Control Protocol) The Real Time Transport Control Protocol (RTP control protocol or RTCP) is based on the periodic transmission of control packets to all participants in the session, using the same distribution mechanism as the data packets. The underlying protocol must provide multiplexing of the data and control packets, for example using separate port numbers with UDP. RTCP performs four functions: 1. RTCP provides feedback on the quality of the data distribution. This is an integral part of the RTP's role as a transport protocol and is related to the flow and congestion control functions of other transport protocols. 2. RTCP carries a persistent transport-level identifier for an RTP source called the canonical name or CNAME. Since the SSRC identifier may change if a conflict is discovered or a program is restarted, receivers require the CNAME to keep track of each participant. Receivers may also require the CNAME to associate multiple data streams from a given participant in a set of related RTP sessions, for example to synchronize audio and video. 3. The first two functions require that all participants send RTCP packets, therefore the rate must be controlled in order for RTP to scale up to a large number of participants. By having each participant send its control packets to all the others, each can independently observe the number of participants. This number is used to calculate the rate at which the packets are sent. 4. An OPTIONAL function is to convey minimal session control information, for example participant identification to be displayed in the user interface. This is most likely to be useful in "loosely controlled" sessions where participants enter and leave without membership control or parameter negotiation. RTP: Real-Time Transport Protocol The real-time transport protocol (RTP) provides end-to-end delivery services for data with real-time characteristics, such as interactive audio and video or simulation data, over multicast or unicast network services. Applications typically run RTP on top of UDP to make use of its multiplexing and checksum services; both protocols contribute parts of the transport protocol functionality. However, RTP may be used with other suitable underlying network or transport protocols. RTP supports data transfer to multiple destinations using multicast distribution if provided by the underlying network. RTP itself does not provide any mechanism to ensure timely delivery or provide other quality-of-service guarantees, but relies on lower-layer services to do so. It does not guarantee delivery or prevent out-oforder delivery, nor does it assume that the underlying network is reliable and delivers packets in sequence. The sequence numbers included in RTP allow the receiver to reconstruct the sender's packet sequence, but sequence numbers might also be used to determine the proper location of a packet, for example in video decoding, without necessarily decoding packets in sequence. RTP consists of two closely-linked parts: The real-time transport protocol (RTP), to carry data that has real-time properties. The RTP control protocol (RTCP), to monitor the quality of service and to convey information about the participants in an on-going session. The latter aspect of RTCP may be sufficient for "loosely controlled" sessions, i.e., where there is no explicit membership control and set-up, but it is not necessarily intended to support all of an application's control communication requirements.

Page 17 of 133

3, VoIP Bandwidth calculations One of the most important factors to consider when you build packet voice networks is proper capacity planning. Within capacity planning, bandwidth calculation is an important factor to consider, when designing and troubleshooting packet voice networks. Please note the IP Office when using G.729a is hard coded to only perform 20ms sampling this can not be changed, this is the same when using G.711 it is fixed at 20ms Every VoIP Packet has a IP/UDP/RTP header of 40 bytes (IP=20 bytes; UDP=8 bytes; RTP=12 bytes) in addition to the VoIP payload and L2 Overheads.

Page 18 of 133

VOIP Bandwidth calculations In the examples below we will be using G.729a @ 20ms
Data Rate kbps Packet Size ms Voice Sample Bytes IP L3 Kbps IPsec Kbps Ether Kbps IP + 802.1Q Kbps IPsec + 802.Q Kbps FR Kbps ATM AAL5 Kbps PPP Kbps

Codec

G.711 G.726 G.729 G.723

64 40 8 5.3

20 10 20 30

160 50 20 20

80.0 72.0 24.0 16.0

102.8 117.6 46.8 31.2

87.2 86.4 31.2 20.8

88.0 88.0 32.0 21.3

110.8 133.6 54.8 36.5

82.4 76.8 26.4 17.6

106.0 127.2 43.2 28.3

83.2 78.4 27.2 18.1

G.729a @ 20ms @ Layer 3 (no Layer 2 Overheads) Above the graph shows 24Kbps see below calculation Total packet size (bytes) = IP/UDP/RTP header of 40 bytes + voice payload of 20 bytes = 60 bytes Total packet size (bits) = (60 bytes) * 8 bits per byte = 480 bits PPS = (8000 Kbps codec bit rate) / (160 bits (20 Bytes)) = 50 packets per second Bandwidth per call = voice packet size (480 bits) * 50 pps = 24.00 Kbps BANDWIDTH ACROSS THE LAN G.729a @ 20ms encapsulated in IPSec @ Layer 3 (no Layer 2 Overheads)

Refer to Network Layer 3 Ip Security (IPSec) Esp in Tunnel Mode with Des or 3 Des later in this document for information on IPSec overheads.
Above the graph shows 46.8Kbps see below calculation Total packet size (bytes) = IP/UDP/RTP header of 40 bytes + voice payload of 20 bytes = 60 Bytes + encapsulated in 57 Bytes of ESP in Tunnel mode = 117 bytes total Total packet size (bits) = (117 bytes) * 8 bits per byte = 936 bits PPS = (8000 Kbps codec bit rate) / (160 bits (20 Bytes)) = 50 packets per second Bandwidth per call = voice packet size (936 bits) * 50 pps = 46.80 Kbps G.729a @ 20ms @ Layer 2 using 802.3 Frame Format no Preamble Above the graph shows 31.2Kbps see below calculation Total packet size (bytes) = IP/UDP/RTP header of 40 bytes + voice payload of 20 bytes = 60 Bytes + encapsulated in 18 Bytes of 802.3 Ethernet with no 8 Byte Preamble= 78 bytes total Total packet size (bits) = (78 bytes) * 8 bits per byte = 624 bits PPS = (8000 Kbps codec bit rate) / (160 bits (20 Bytes)) = 50 packets per second Bandwidth per call = voice packet size (624 bits) * 50 pps = 31.20 Kbps G.729a @ 20ms @ Layer 2 using 802.1q frame format (Vlan) no Preamble Above the graph shows 32.00Kbps see below calculation Total packet size (bytes) = IP/UDP/RTP header of 40 bytes + voice payload of 20 bytes = 60 Bytes + encapsulated in 20 Bytes of 802.1q no preamble = 80 bytes total Total packet size (bits) = (80 bytes) * 8 bits per byte = 640 bits PPS = (8000 Kbps codec bit rate) / (160 bits (20 Bytes)) = 50 packets per second Bandwidth per call = voice packet size (640 bits) * 50 pps = 32.00 Kbps

SPEECH

Page 19 of 133

G.729a @ 20ms encapsulated in IPSec, encapsulated in 802.1q frame format no Preamble Above the graph shows 54.80Kbps see below calculation Total packet size (bytes) = IP/UDP/RTP header of 40 bytes + voice payload of 20 bytes = 60 Bytes + encapsulated in 57 Bytes of ESP IPSec + 20 Bytes of 802.1q = 137 bytes total Total packet size (bits) = (137 bytes) * 8 bits per byte = 1096 bits PPS = (8000 Kbps codec bit rate) / (160 bits (20 Bytes)) = 50 packets per second Bandwidth per call = voice packet size (1096 bits) * 50 pps = 54.80 Kbps G.729a BANDWIDTH ACROSS THE WAN G.729a @ 20ms encapsulated in Frame Relay. For example a Frame Relay Connection Above the graph shows 26.4Kbps see below calculation Total packet size (bytes) = IP/UDP/RTP header of 40 bytes + voice payload of 20 bytes = 60 bytes + 6 Bytes Frame Relay header = 66 Bytes Total packet size (bits) = (66 bytes) * 8 bits per byte = 528 bits PPS = (8000 Kbps codec bit rate) / (160 bits (20 Bytes)) = 50 packets per second Bandwidth per call = voice packet size (528 bits) * 50 pps = 26.40 Kbps G.729a @ 20ms over ATM AAL5 For example a SHDSL connection Above the graph shows 43.2Kbps see below calculation Total packet size (bytes) = IP/UDP/RTP header of 40 bytes + voice payload of 20 bytes = 60 Bytes + 48 Bytes of AAL5 SAR PUD (ATM)= 108 bytes total Total packet size (bits) = (108 bytes) * 8 bits per byte = 864 bits PPS = (8000 Kbps codec bit rate) / (160 bits (20 Bytes)) = 50 packets per second Bandwidth per call = voice packet size (864 bits) * 50 pps = 43.20 Kbps G.729a @ 20ms over PPP in HDLC like framing (Not MLPPP) For example a dial up PPP Connection Above the graph shows 27.2Kbps see below calculation Total packet size (bytes) = IP/UDP/RTP header of 40 bytes + voice payload of 20 bytes = 60 Bytes + 8 Bytes of PPP in HDLC like Framing= 68 bytes total Total packet size (bits) = (68 bytes) * 8 bits per byte = 544 bits PPS = (8000 Kbps codec bit rate) / (160 bits (20 Bytes)) = 50 packets per second Bandwidth per call = voice packet size (544 bits) * 50 pps = 27.20 Kbps G.729a @ 20ms over MPLS For example a Single G.729a call over a MPLS core Total packet size (bytes) = IP/UDP/RTP header of 40 bytes + voice payload of 20 bytes = 60 Bytes + 6 Bytes of MPLS Header = 66 bytes total Total packet size (bits) = (66 bytes) * 8 bits per byte = 528 bits PPS = (8000 Kbps codec bit rate) / (160 bits (20 Bytes)) = 50 packets per second Bandwidth per call = voice packet size (528 bits) * 50 pps = 26.40 Kbps

Page 20 of 133

In the examples below we will be using G.711 @ 20ms

Data Rate kbps Packet Size ms Voice Sample Bytes IP L3 Kbps IPsec Kbps Ether Kbps IP + 802.1Q Kbps IPsec + 802.Q Kbps FR Kbps ATM AAL5 Kbps PPP Kbps

Codec

G.711 G.726 G.729 G.723

64 40 8 5.3

20 10 20 30

160 50 20 20

80.0 72.0 24.0 16.0

102.8 117.6 46.8 31.2

87.2 86.4 31.2 20.8

88.0 88.0 32.0 21.3

110.8 133.6 54.8 36.5

82.4 76.8 26.4 17.6

101.2 127.2 43.2 28.3

83.2 78.4 27.2 18.1

G.711 @ 20ms @ Layer 3 (no Layer 2 Overheads) Above the graph shows 80Kbps see below calculation Total packet size (bytes) = IP/UDP/RTP header of 40 bytes + voice payload of 160 bytes = 200 bytes Total packet size (bits) = (200 bytes) * 8 bits per byte = 1600 bits PPS = (64000 Kbps codec bit rate) / (1280 bits (160 Bytes)) = 50 packets per second Bandwidth per call = voice packet size (1600 bits) * 50 pps = 80.00 Kbps G.711 BANDWIDTH ACROSS THE LAN G.711 @ 20ms encapsulated in IPSec @ Layer 3 (no Layer 2 Overheads)

Refer to Network Layer 3 Ip Security (IPSec) Esp in Tunnel Mode with Des or 3 Des later in this document for information on IPSec overheads.
Above the graph shows 102.8Kbps see below calculation Total packet size (bytes) = IP/UDP/RTP header of 40 bytes + voice payload of 160 bytes =200 Bytes + encapsulated in 57 Bytes of ESP in Tunnel mode = 257 bytes total Total packet size (bits) = (257 bytes) * 8 bits per byte = 2056 bits PPS = (64000 Kbps codec bit rate) / (1280 bits (160 Bytes)) = 50 packets per second Bandwidth per call = voice packet size (2056 bits) * 50 pps = 102.80 Kbps

G.711 @ 20ms @ Layer 2 using 802.3 Frame Format no Preamble Above the graph shows 87.2Kbps see below calculation Total packet size (bytes) = IP/UDP/RTP header of 40 bytes + voice payload of 20 bytes = 200 Bytes + encapsulated in 18 Bytes of 802.3 Ethernet with no 8 Byte Preamble= 218 bytes total Total packet size (bits) = (218 bytes) * 8 bits per byte = 1744 bits PPS = (64000 Kbps codec bit rate) / (1280bits (160Bytes)) = 50 packets per second Bandwidth per call = voice packet size (1744 bits) * 50 pps = 87.20 Kbps G.711 @ 20ms @ Layer 2 using 802.1q frame format (Vlan) no Preamble Above the graph shows 88.0Kbps see below calculation Total packet size (bytes) = IP/UDP/RTP header of 40 bytes + voice payload of 160 bytes = 200 Bytes + encapsulated in 20 Bytes of 802.1q no preamble = 220 bytes total Total packet size (bits) = (220 bytes) * 8 bits per byte = 1760 bits PPS = (64000 Kbps codec bit rate) / (1280 bits (160 Bytes)) = 50 packets per second Bandwidth per call = voice packet size (1760 bits) * 50 pps = 88.00 Kbps

SPEECH

Page 21 of 133

G.711 @ 20ms encapsulated in IPSec, encapsulated in 802.1q frame format no Preamble Above the graph shows 110.80Kbps see below calculation Total packet size (bytes) = IP/UDP/RTP header of 40 bytes + voice payload of 160 bytes = 200 Bytes + encapsulated in 57 Bytes of ESP IPSec + 20 Bytes of 802.1q = 277 bytes total Total packet size (bits) = (277 bytes) * 8 bits per byte = 2216 bits PPS = (64000 Kbps codec bit rate) / (1280 bits (160Bytes)) = 50 packets per second Bandwidth per call = voice packet size (2216 bits) * 50 pps = 110.80 Kbps G.711 BANDWIDTH ACROSS THE WAN G.711 @ 20ms encapsulated in Frame Relay. For example a Frame Relay Connection Above the graph shows 82.40Kbps see below calculation Total packet size (bytes) = IP/UDP/RTP header of 40 bytes + voice payload of 160 bytes = 200 bytes + 6 Bytes Frame Relay header = 206 Bytes Total packet size (bits) = (206 bytes) * 8 bits per byte = 1648 bits PPS = (64000 Kbps codec bit rate) / (1280 bits (160 Bytes)) = 50 packets per second Bandwidth per call = voice packet size (1648 bits) * 50 pps = 82.40 Kbps G.711 @ 20ms over ATM AAL5 For example a SHDSL connection Above the graph shows 101.2Kbps see below calculation Total packet size (bytes) = IP/UDP/RTP header of 40 bytes + voice payload of 160 bytes = 200 Bytes + 53 Bytes of AAL5 SAR PUD (ATM)= 253 bytes total Total packet size (bits) = (253 bytes) * 8 bits per byte = 2024bits PPS = (64000 Kbps codec bit rate) / (1280 bits (160 Bytes)) = 50 packets per second Bandwidth per call = voice packet size (2024 bits) * 50 pps = 101.20 Kbps G.711 @ 20ms over PPP in HDLC like framing (Not MLPPP) For example a dial up PPP Connection Above the graph shows 83.2Kbps see below calculation Total packet size (bytes) = IP/UDP/RTP header of 40 bytes + voice payload of 160 bytes = 200 Bytes + 8 Bytes of PPP in HDLC like Framing= 208 bytes total Total packet size (bits) = (208 bytes) * 8 bits per byte = 1664 bits PPS = (64000 Kbps codec bit rate) / (1280 bits (160 Bytes)) = 50 packets per second Bandwidth per call = voice packet size (1664 bits) * 50 pps = 83.20 Kbps

Page 22 of 133

IPO/IPNC performs Voice Traffic concurrent call load restriction on a per call basis and does not assume the bandwidth requirement. The actual bandwidth requirement for any given number of VoIP calls must be determined with respect Compression/Codec type (i.e. G711 or G729a) and the status of cRTP on the link. The table below is included here in order to illustrate this principle

Number of allowed calls 1

1 10 15

Compression Codec Type

G729a G729a G729a G729a

cRTP
No Yes No Yes

Minimum Bandwidth Kbps Over Frame Relay with

RFC1490+FRF12

(1 * 26) =26 (1 * 12)= 12 (26 * 10) =260 (12 * 15) =180

The table shows, for example, that if cRTP is running and there is a requirement for 15 concurrent G729 calls that a minimum bandwidth or CIR rate of 180Kbps is required. In this case the VPN Line parameter Number Of Channels would be set to 15 and the CIR rate would a minimum of 180Kbps. The number of VoIP calls that can occupy a link is directly related to the CIR rate of the link. As General rule when mixing voice and data on the same DLCI it is recommended that no more than 75% of the available bandwidth be used for VoIP traffic; use the IPO/IPNC VPN Line to restrict the number of concurrent calls that are allowed to occupy the link. For further information regarding implementing the IPO in a Frame Relay environment please refer to IPOfficeTech019FRF12.pdf available from the IPL Communication Helpdesk. To work out how much bandwidth you would use per hour use the following formula kbps *3600 (seconds in an hour) = kilobits per hour kilobits per hour /1024 (convert into megabits)=megabits per hour megabits per hour /8 (8 bits in a byte) = Megabytes (MB) per hour. G.711 @ 20ms @ Layer 3 (no Layer 2 Overheads) G711 = (80000x3600) /1024 /8 = around 35MB per hour. G.729a @ 20ms @ Layer 3 (no Layer 2 Overheads) G729 = (24000x3600) /1024 /8 = around 10MB per hour.

Page 23 of 133

cRTP Compressed Real-Time Protocol (cRTP) reduces the IP/UDP/RTP headers to 2or 4bytes (cRTP is not available over Ethernet). All VoIP packets are made up of two components: voice samples and IP/UDP/RTP headers. Although the voice samples are compressed by the Digital Signal Processor (DSP) and may vary in size based on the codec used, these headers are a constant 40 bytes in length. When compared to the 20 bytes of voice samples in a default G.729a call, these headers make up a considerable amount of overhead. Using cRTP, these headers can be compressed to two or four bytes. This compression offers significant VoIP bandwidth savings. For example, a default G.729 VoIP call consumes 24 Kb @ Layer 3 without cRTP, but only 12 Kb with cRTP enabled. The IP Office only performs cRTP on its WAN interface NOT on its LAN interface which is used when connecting to WAN via a Third Party router cRTP would be performed at this point. cRTP is not recommended to be used on routers with high CPU usage. Silence Suppression (VAD) In Voice over IP (VoIP), voice activation detection (VAD) is a software application that allows a data network carrying voice traffic over the Internet to detect the absence of audio and conserve bandwidth by preventing the transmission of "silent packets" over the network. Most conversations include about 50% silence; VAD (also called "silence suppression") can be enabled to monitor signals for voice activity so that when silence is detected for a specified amount of time, the application informs the Packet Voice Protocol and prevents the encoder output from being transported across the network. VAD can some times introduce voice clipping and variance in speech quality. These technical notes above are provided to give the end user or reseller an idea of VoIP bandwidth requirements only. There are many more factors that can affect VoIP quality, such as queuing mechanisms, fragmentation, interleaving types, as well as carriers, general networking rules, overall network design, hardware used, end to end delay, packet classification (CoS), IPO Small Community networking traffic and many more.

Page 24 of 133

4, VoIP through Firewalls The difficulties of using VoIP connections through firewalls. An H.323 call is made up of many different simultaneous connections. At least two of the connections are TCP. For an audio-only conference, there may be up to 4 different UDP `connections' made. All of these connections except one are made to ephemeral (dynamic) ports. Below Is a brief outline of the call to help you understand the difficulties that are involved with using VoIP & Firewalls, the main drawback is because of the number of ports used and the fact that many are dynamic. Brief Outline of a Call:The call is basically managed at three different layers. It's starts by making a TCP connection to the well known port for H.323, port 1720. NOTE: An exception is the 46xx IP Hard Phones which use 1719 by default. The two ends then send Q.931 signalling packets across this connection. As part of this exchange, both ends also send an ephemeral (dynamic port number) port number to be used for the H.245 connection. The H.245 connection is made from the caller to the ephemeral port negotiated within the Q.931 stream. H.245 also has commands that cause UDP connections to be made. Essentially, once the audio (and video, in some cases) codecs eg: G729a and parameters have been negotiated, the H.245 session executes an Open Logical Channel sequence. This sequence sends the transmitter's RTCP address and port number as well as the receiver's RTP and RTCP address and port number. Also, the RTP protocol requires two UDP `connections', using adjacent streams. The associated RTCP and RTP streams are required to be one port apart (with the RTP port being even and the RTCP being the next higher odd). Because of H.323's heavy use of ephemeral (dynamic) ports, the only way for a packet filtering router to support H.323 is to open up all UDP and TCP ports used in each direction. This policy does not provide much protection as it opens a large number of ports on your firewall. The main difficulty is that the addresses and port numbers are exchanged within the data stream of the `next higher' connection. For example, the port number for the H.245 connection is established within the Q.931 data stream (This makes it particularly difficult for address translating firewalls, which must modify the addresses inside those data streams.) For these reasons we do not recommend running VoIP through our firewall, and if a firewall is a necessity you should look into getting a "VoIP" aware dedicated firewall system which is capable of interrogating the data streams to determine which port number is going to be used next. For the reasons above we do not suggest using / performing VoIP through NAT.

Page 25 of 133

5, Standard IPO/IPNC Ports

Note that 0x denotes the following digits are in Hexadecimal.

Call Setup Ports: = H.323v2 well known port number = TCP - 1720 (0x6B8) (Note: 46xx / 56xx (IP Hard Phones) uses TCP 1719 (0x6B7) by default) (IPO Voice Networking): Small Community Network signalling (AVRIP) and BLF updates. Port 50795 (UDP) (VOIP Voice Stream are transmitted encapsulated in RTP which is transmitted via UDP) Port range: = 49152 - 53247 0xC000 - 0xCFFF) Matching Voice Stream in router as default IPO configuration on Cisco EF = 101110 See below explanation, for further information refer to section 13 of this document. TOS (Type of Service) 8 Bit octet of an IPv4 header is renamed the Differentiated Services (DS) Field by DiffServ. The structure of the DS field is depicted below: 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | DSCP | CU | +---+---+---+---+---+---+---+---+ DSCP: Differentiated Service Code Point, the leftmost 6 bits in the field. Below see screen shot of a default IPO configuration where the IPO is marking the packets with 46 Dec which equals101110 binary this makes up 6 bits required by the DSCP field. Cisco Routers will match this on Expedited forwarding (EF) access-list XXX permit udp any any dscp ef

VOIP and IP Office Networking TCP/UDP Ports

Page 26 of 133

IPO Application Port Numbers

Note that 0x denotes the following digits are in Hexadecimal.

Port 69 (Trivial File Transfer): File requests to the IP Office. Port 69 (Trivial File Transfer): File requests by the IP Office. Port 161 (SNMP): From SNMP applications. Port 162 (SNMP Trap): To addresses set in the IP Office configuration. Both SNMP Port numbers can be changed through the IP Office configuration. Port 520 RIP: From IP Office to other RIP devices. For RIP1 and RIP2 (RIP1 compatible) the destination address is a subnet broadcast, eg. 192.168.42.255. For RIP2 Multicast the destination address is 224.0.0.9. Port 520 RIP: To the IP Office from RIP devices. Port 1719 (H.323 RAS): Response to a VoIP device registering with IP Office. Port 1720 (H.323/H.245): Data to a registered VoIP device. Port 2127: PC Wallboard to CCC Wallboard Server. Port 8080: Browser access to the Delta Server application. Port 8089: Conferencing Center Server Service. Port 8888: Browser access to the IP Office Contact Store (VRL) application. Ports 49152 to 53247: Dynamically allocated ports used during VoIP calls for RTP and RTCP traffic. The port range can be adjusted through the System | Gatekeeper tab. Port 50791 (IPO Voicemail): To voicemail server address. Port 50793 (IPO Solo Voicemail): From IP Office TAPI PC with Wave drive user support. Port 50794 (IPO Monitor): From the IP Office Monitor application. Port 50795 (IPO Voice Networking): Small Community Network signalling (AVRIP) and BLF updates. Port 50796 (IPO PCPartner): From an IP Office application (for example Phone Manager or SoftConsole). Used to initiate a session between the IP Office and the application. Port 50797 (IPO TAPI): From an IP Office TAPI user PC. Port 50799 (IPO BLF): Broadcast to the IP Office LAN, eg. 255.255.255.255. Port 50800 (IPO License Dongle): To the License Server IP Address set in the IP Office config. Port 50801 (EConf): Used by the Conference Center service.Port Port 50802 (TCP) (Discovery) Used by the IP Office to listen for discovery attempts from the Manager Select IP Office menu. Port 50804 (TCP) (Configuration) Manager configuration settings access to an IP Office 3.2 system. Port 50808 (TCP) (Security Settings) Manager security settings access to an IP Office 3.2 system. Standard IPNC Port Numbers

Note that 0x denotes the following digits are in Hexadecimal.

Call Setup Ports: = H.323 well known port number = TCP - 1720 (0x6B8) (Note: 46xx (IP HardPhone) uses 1719 (0x6B7) by default) RTP UDP Port numbers: = RTP voice stream = UDP - 49152 - 53247 (0xC000 - 0xCFFF DPNSS = 4100 4130 TCP

Page 27 of 133

6, Quality Of Service On IP based networks, QoS (Quality of Service) is the idea that transmission rates, error rates, and other characteristics can be measured, improved, and, to some extent, guaranteed in advance. QoS is of particular concern for the continuous transmission of high-bandwidth video and multimedia information such as VoIP. 7, Class Of Service-Type Of Service Class of Service (CoS) is a way of managing traffic in a network by grouping similar types of traffic (for example, e-mail, streaming video, voice, large document file transfer) together and treating each type as a class with its own level of service priority. Unlike Quality of Service (QoS) traffic management, Class of Service technologies do not guarantee a level of service in terms of bandwidth and delivery time; they offer a "best-effort." On the other hand, CoS technology is simpler to manage and more scalable as a network grows in structure and traffic volume. One can think of CoS as "coarsely-grained" traffic control and QoS as "finely-grained" traffic control. There are three main CoS technologies: 802.1p Layer 2 Tagging (Supported by 46XX Phones) Type of Service (ToS) (Supported by 46XX Phones) Differentiated Services (DiffServ) (Supported by IPO and IPNC and 46XX Phones) 802.1p Layer 2 Tagging and ToS make use of three bits in the layer 2 packet header that can be used to specify priority. Since three bits does not allow for much sophistication in managing traffic, a new protocol, Differentiated Services (DS or DiffServ), has been developed. Differentiated Services uses a different approach to managing packets than simple priority labeling. It uses an indication of how a given packet is to be forwarded, known as the Per Hop Behavior (PHB). The PHB describes a particular service level in terms of bandwidth, queuing theory, and dropping (discarding the packet) decisions. The Differentiated Services protocol exists as a set of related working documents from the Internet Engineering Task Force (IETF). Differentiated Services (DiffServ, or DS) is a protocol for specifying and controlling network traffic by class so that certain types of traffic get precedence - for example, voice traffic, which requires a relatively uninterrupted flow of data, might get precedence over other kinds of traffic. Differentiated Services is the most advanced method for managing traffic in terms of what is called Class of Service (CoS). Unlike the earlier mechanisms of 802.1p tagging and Type of Service (ToS), Differentiated Services avoids simple priority tagging and depends on more complex policy or rule statements to determine how to forward a given network packet. An analogy is made to travel services, in which a person can choose among different modes of travel - train, bus or airplane - degree of comfort, the number of stops on the route, standby status, the time of day or period of year for the trip, and so forth. For a given set of packet travel rules, a packet is given one of 64 possible forwarding behaviours - known as per hop behaviours (PHBs). A six-bit field, known as the Differentiated Services Code Point (DSCP), in the Internet Protocol (IP) header specifies the per hop behaviour for a given flow of packets. Differentiated Services and the Class of Service approach provide a way to control traffic that is both more flexible and more scalability than the Quality of Service approach. IPL Communication would refer interested parties that want to learn more about VoIP to read the following book to gain an in-depth knowledge of data and voice networking/internetworking. Voice and Data Internetworking (Third Edition) By Gil Held: http://www.amazon.com

Page 28 of 133

8, Ensuring Quality Of Service Over IP by AVAYA Section 1: Section 2: Section 3: Section 4: Executive Summary Definitions IP Voice Quality Network Requirements Prioritising Voice Traffic Understanding CoS versus QoS Using Ports Using DSCP (or TOS) Using IEEE 802.1 p/Q Using VLANs Network Parameters Network Delay Network Jitter Packet Loss Network Packet Loss Network Packet Mis-Order Transcoding Echo Silence Suppression and Voice Activity Detection Network Duplex Codec Selection Bandwidth Requirements Other Elements that affect QoS WAN Considerations VPN Conclusion

Section 5:

Section 6: Section 7:

Section 8: 1 ExecutiveSummary Internet Protocol (IP) Telephony - where voice communication and computer data are transmitted over a single network offers the promise of simplified administration, significant cost savings and easier integration of voice and data applications. Ensuring Quality of Service (QoS) poses some fundamental challenges for organizations embarking on, or making improvements to, an IP telephony network. Delay produced by network elements such as routers, switches and signal processors may not adversely affect data communication, yet can noticeably degrade voice communication. Variation in delay, called jitter, can also damage voice quality. When sent over a packet data network, voice packets are likely to require priority processing in order to reduce delay and jitter, and help ensure that QoS meets the expectations of callers. This white paper outlines the main technical issues organizations should consider to ensure QoS, based on the latest research of Avaya Labs Australia and the extensive experience of Avaya in IP telephony deployments worldwide. There are a range of tools to consider in the assessment, implementation and management of networks, designed to meet the demands of voice communication and facilitate ways to achieve QoS. Organizations should not expect to simply add voice to an existing data network, without making additional adjustments. Networks that handle data traffic may require upgrades and special management techniques to meet the more stringent requirements of voice applications. The benefits of IP telephony, however, usually justify the investment.

Page 29 of 133

T h e B e n e f i t s o f I P Te l e p h o n y Running voice, as well as data, over Internet Protocol (IP) provides: better applications by using a common protocol lower costs through integration of separate support staff. Other real-time traffic, such as uncompressed video and streaming audio, is also converging onto data networks. IP Telephony Benefits Definitions IP Telephony refers to the transmission of voice communication over an IP network. This is also called Voice over IP (VoIP) or convergence. Quality of Service (QoS) refers to the performance quality guarantees required in the transmission of voice communication over IP networks. Virtual Private Networks (VPNs), in this white paper, refers to encrypted tunnels carrying packetised data between remote sites. 2 IPQualityofServiceNetworkRequirements Ensuring Quality of Service (QoS) over IP is complex because it involves components of both the data and voice networks. Traditionally, data and voice have used: two different networks, two different support organizations, two different philosophies. Organizations have traditionally kept voice networks separate from data networks. This is because the characteristics of voice applications and the protocols used are very different from those of data applications. Voice calls have generally had dedicated bandwidth through the circuit switched network, where five nines reliability became the standard. IP telephony traffic is sensitive to delay and jitter but can tolerate some packet loss, problems that were rarely an issue with circuit switching. A data network is packet switched, and less sensitive to delay and jitter, but cannot tolerate loss. The data philosophy has centered on providing reliable data transmission over unreliable media, almost regardless of delay. Bandwidth for data is largely shared, so congestion and delay are often present. This can cause problems for multimedia applications, such as voice. Factors that affect the quality of data transmission are different from those affecting the quality of voice transmission. For example, as mentioned previously data is generally not affected by delay. By comparison, voice transmissions are degraded by relatively small amounts of delay and cannot be retransmitted. A tiny amount of packet (data) loss does not affect voice quality at the receivers ear, but even a small loss of data can corrupt an entire file or application. So in some instances, introducing voice to a high performing IP network can yield poor voice quality. 4 Ensuring QoS for IP telephony requires attention to many factors, including: Delay Jitter Packet loss Packet mis-order Available bandwidth Packet prioritisation Network design Endpoint audio characteristics (sound card, microphone, earpiece, etc.) Duplex Transcoding Echo Silence suppression Codec selection Router and data-switch configuration Reliability Scalability Manageability Wide Area Network (WAN) protocols QoS/CoS (Class of Service) policy Encryption/Decryption 5

Page 30 of 133

PrioritisingVoiceTraffic For an IP telephony solution to function well in organisations, the network must be able to give voice packets priority over ordinary data packets, unless sufficient dedicated bandwidth is always available for the voice packets. Understanding CoS versus QoS Class of Service (CoS) is a classification method only. CoS does not ensure a level of Quality of Service (QoS), but is the method used by queuing mechanisms to limit delay and other factors to improve QoS. Most CoS strategies assign a priority level, usually 0-7 or 0-63, to a frame or packet respectively. Common CoS models include: IP Type Of Service (TOS) byte, Differentiated Services Code Point (DSCP) or DiffServ, defined in (RFC) 2474 and others. IEEE 802.1p/Q standard. QoS involves giving preferential treatment through queuing, bandwidth reservation, or other methods based on attributes of the packet, such as CoS priority. A service quality is then negotiated. Examples of such QoS techniques are: Class Based Weighted Fair Queuing (CBWFQ) Resource Reservation Protocol (RSVP) RFC 2205. Multi Protocol Label Switching (MPLS) RFC 3031 and others. CoS, or tagging, is totally ineffective in the absence of QoS techniques because it can only mark data. QoS relies on tags or filters to give priority to data streams. Using Ports User Datagram Protocol (UDP) is used to transport voice through the Local Area Network (LAN) because, unlike Transmission Control Protocol (TCP), it is not connection based. One prioritization scheme assigns priority based on the UDP port numbers used by the voice packets. This allows the use of network equipment to prioritise all packets from a port range. As the human ear is sensitive to delay, it is better to drop packets rather than retransmit voice in a real time environment. Accordingly, a connectionless protocol is preferable to a connection-based protocol. By using Avaya Communication Manager, users can define a port range for voice priority. Routers and layer 3 data switches can then use these ports to distinguish priority traffic. Priority traffic can be voice packets (UDP), signaling packets (TCP) or both. This is an Open Systems Interconnection (OSI) model layer 4 solution and works on data coming to and from the specified ports or port range. Using DSCP (or TOS) The Differentiated Services Code Point (DSCP) prioritization scheme redefines the existing Type of Service (TOS) byte in the IP header by combining the first six bits into 64 possible combinations. Use of the TOS byte is still evolving but can be used now by: IP Office and Index IPNC IP Telephones Network elements such as routers and switches in the LAN and WAN. A DSCP of 46 (101110) is suggested for the expedited forwarding of voice and signaling packets. Older routers may require a DSCP setting of 40 (101000), which is backward compatible to the original TOS byte definition of critical. The TOS byte is an OSI model layer 3 solution and works on IP packets on the LAN, and possibly the WAN, depending on the service provider. Using IEEE 802.1 p/Q Standards Another prioritisation scheme is the IEEE 802.1Q standard, which uses two bytes to augment the layer 2 header. IEEE 802.1Q defines the open standard for Virtual Local Area Networks (VLAN) tagging. Two bytes house 12 bits used to tag each frame with a VLAN identification number. The IEEE 802.1p standard uses three of the remaining bits in the 802.1Q header to assign one of eight different classes of service.

Page 31 of 133

Using VLANs Virtual Local Area Networks (VLANs) provide limited security and create smaller broadcast domains through software by creating virtually separated subnets. As organizations generally require a high level of security, careful consideration should be given to the set-up of VLANs. Broadcasts are a natural occurrence in data networks from protocols used by PCs, servers, switches, routers, Network Operating System (NOS), etc. Creating a separate VLAN for voice reduces the amount of broadcast traffic (and unicast traffic on a shared LAN) the telephone will receive. Separate VLANs result in more effective bandwidth utilization and reduces the processor burden on the IP telephones and PCs by freeing them from having to analyze irrelevant broadcast packets. VLANs, a layer 2 feature, are created in data switches. A voice VLAN can also be manually applied to an IP telephone or given by a Dynamic Host Configuration Protocol (DHCP) server. CoS tagging and QoS policies can be applied at OSI layer 2 by using VLANs. Separate voice and data VLANs are a sensible option for many organizations and are highly recommended by Avaya. Suggested QoS mechanisms in an IP telephony network

NetworkParameters There are a number of network parameters that affect voice quality. The concept of quality has different meanings to different organizations. IP telephony quality can be engineered to several different levels to accommodate differing organizational needs. Avaya presents options in network requirements to allow organizations to choose a level of quality which best suits their specific needs.

Page 32 of 133

Network Packet Delay Packet delay is the length of time it takes a packet to traverse the network. Each element of the network adds to packet delay including switches, routers, distance traveled through the network, firewalls, and jitter buffers, such as those built into H.323 audio applications like the Avaya IP Softphone or Microsoft NetMeeting. Router delay depends not only on hardware, but also on configurations such as access lists, queuing methods, and transmission modes. Delay often referred to as latency can have a noticeable effect but can be controlled somewhat in a private network environment (LAN/WAN) because the organization manages the network infrastructure to a certain Service Level Agreement (SLA). When using the public network, there are inherent delays that cannot be controlled. A network delay value between endpoints, i.e. LAN/WAN measurements not including IP phones of: 80ms (milliseconds) delay or less can, but may not, yield toll quality. 80ms to 180ms delay can give business communication quality. This is much better than mobile phone quality and is suited for the majority of organizations. Delays exceeding 180ms may still be quite acceptable depending on customer expectations, analog trunks used, codec type, etc. The Telecommunication Standardization Sector of the International Telecommunications Union (ITU)-T has recommended 150ms one-way delay (including endpoints) as the limit for excellent voice quality. This value is largely misinterpreted as the only range to calculate a network delay budget for IP telephones. A network delay budget of 230ms proved almost imperceptible in experiments at Avaya Labs. Importance of a Network Assessment A network assessment is highly recommended to measure delay (and other factors) and make recommendations to solve any delay issues before implementing an IP solution. 9 One-way delays in excess of 250ms can cause the well-known problem of talk-over, when each person starts to talk because the delay prevents them from realising that the other person has already started talking. Staying within 150ms (end-to-end) may not be possible. End-to-end delay over 400ms can cause port network instability. Long WAN transports must be considered as a major contributor to the network delay budget. For example: One major WAN service provider averaged 75ms delay from Los Angeles to New York. Los Angeles to Paris was found to be about 145ms. Some WAN service providers can lower delay in their network if it is negotiated and recorded as part of the companies Service Level Agreement (SLA) Network Jitter Jitter is a measure of variance in the time it takes for communications to traverse from the sender (application) to the receiver. As seen from the application layer (from RFC_2729 Taxonomy of Communication Requirements for Large-scale Multicast Applications), jitter is thought of as the statistical average variance in delivery time between packets or datagrams. Jitter can create audible voice-quality problems if the variation is greater than 20ms (assuming an existing 20ms packet size). Symptoms of excessive jitter are very similar to symptoms of high delay, because in both cases packets are discarded if the packet delay exceeds half the jitter buffer size. To compensate for network jitter, many vendors implement a jitter buffer in their H.323 voice applications. A jitter buffer is designed to: Hold incoming packets for a specified period of time before forwarding them to the decompression process. Smooth packet flow. In doing so, it can also add packet delay. Jitter buffers should be dynamic to give the best quality, or if static, should be sized to twice the largest statistical variance Between packets. 10 Router vendors have many queuing methods that alter the behavior of the jitter buffer. It is not enough to just select the right size of jitter buffer, but also pair an appropriate queue-unloading algorithm type with the jitter buffer.

Page 33 of 133

Network topology can also affect jitter. There will be less jitter on the switched network, because there are fewer collisions on a data-switched network, than on a hub-based network. Jitter buffers can exacerbate problems in an uncontrolled network. Many good tools are available to measure jitter, delay, and packet loss to help monitor and bring control to the network. Packet Loss Network packet loss occurs when packets are sent, but not received at the final destination, due to some network problem. Qualifying problems caused by occasional packet loss are difficult to detect because each codec has its own packet loss concealment method. It is possible that voice quality would be better using a compression codec (G.729A) compared to a full bandwidth G.711 codec. Factors affecting Packet Loss requirements Packet loss requirements are therefore tighter for tones (other than for Dual Tone Multi Frequency (DTMF) than for voice. The ear is less able to detect packet loss during speech (variable-pitch), than during a tone (consistent pitch). Packet loss requirements are tighter for short, continuous packet loss than for random packet loss over time. Losing ten contiguous packets is worse than losing ten packets evenly spaced over an hour time span. Packet loss may be more noticeable for larger voice payloads than for smaller ones, because more voice is lost in a larger payload. Packet loss may be more tolerable for one codec over another. Even small amounts of packet loss can greatly affect Telecommunications Device for the Deaf (TTY) or Telecommunications Display Device (TDD) devices ability to work properly. Packet loss for TCP signaling traffic increases substantially over 3% loss due to retransmissions. Network Packet Loss The maximum loss of packets (or frames) between endpoints of: 1% or less can yield toll quality depending on many factors. 3% or less should give business communications quality. This quality is much better than mobile-phone quality. More than 3% may be acceptable for voice but may interfere with signaling. Too much delay or packet mis-order can cause dropped packets, and it may appear that the network is losing packets when in fact they have been discarded intentionally. Network Packet Mis-Order For IP telephony network packet mis-order is similar to packet loss. If a packet arrives out of order, it is generally discarded, as it makes no sense to play it out of order and buffers are small. Specifically, packets are discarded when they arrive later than the jitter buffer can hold them. Mis-order can occur when networks send individual packets over different routes. Packet mis-order can be caused by planned events, like load-balancing or unplanned events such as re-routing due to congestion, or other transient difficulties. Packets traversing the network over different routes may arrive at their destination out of order. Network delay over multiple yet unequal routing paths can also force packet misorder. Transcoding Transcoding is a voice signal converted from analog to digital or digital to analog (possibly with or without compression and decompression). If calls are routed using multiple voice coders, as in the case of call coverage on an intermediary system back to a centralised voice mail system, the calls may experience multiple transcoding (including the message in and out of the voice mailbox). Each transcoding episode results in some degradation of voice quality. 11 Echo The two main types of echo are: Acoustic Impedance There are many potential sources of echo. It occurs when a VoIP call leaves the LAN through a poorly administered analog trunk into the Public Switch Telephone Network (PSTN). Another major cause is from an impedance mismatch between four-wire and two wire systems. Echo also results when an Page 34 of 133

impedance mismatch exists in the conversion between the Time Division Multiplexing (TDM) bus and the LAN, or the impedance mis-match between a headset and its adapter. Impedance mis-match causes inefficient energy transfer. The energy imbalance must go somewhere and so it is reflected back in the form of an echo. Usually the speaker hears an echo but the receiver does not. Echo cancellers, which have varying amounts of memory, compare the received voice with the current voice patterns. If the patterns match, the canceller cancels the echo. Echo cancellers are not perfect. Under some circumstances, the echo gets past the canceller. The problem is exacerbated in IP telephony systems. If the one-way trip delay between endpoints is larger than the echo canceller memory, the echo canceller will not be able to find a pattern to cancel. Silence Suppression and Voice Activity Detection Voice Activity Detection (VAD) monitors the received signal for voice activity. When no activity is detected for the configured period of time, Avaya software informs the Packet Voice Protocol. This prevents the encoder output from being transported across the network when there is silence, resulting in additional bandwidth savings. Avaya software also measures the idle noise characteristics of the telephony interface. It reports this information to the Packet Voice Protocol to relay this information to the remote end for comfort noise generation when no voice is present. Aggressive VADs cause voice clipping and can result in poor voice quality. The use of VAD can greatly conserve bandwidth, and is important to consider when planning network bandwidth especially in the WAN. Echo cancellers designed to improve voice quality for IP telephony are incorporated in: Avaya IP Office, Avaya 4600 Series IP telephones. 12 Network Duplex The ideal LAN network for transporting VoIP traffic is a network that is fully switched from end-to-end because it significantly reduces or eliminates collisions. A network that has shared segments (hub-based) can result in lower voice quality, due to excessive collisions. Ethernet connections from Avaya hardware default to auto-negotiation for speed and duplex to work the network endpoints right away. Avaya recommends that connections become set value static links because of known problems with the way auto-negotiation was designed. With Avaya Communication Manager; the control LAN (CLAN), Media Processor, IPSI etc. connections should be set to 100Mbps and full duplex and also at the Ethernet data switch to which it terminates. IP telephones use auto-negotiation, and older versions of circuit cards may require different speed and/or duplex settings. Codec Selection Depending upon the bandwidth availability and acceptable voice quality, it might be worthwhile to select a coder/decoder (codec) that produces compressed audio. A G.711 codec produces audio uncompressed to 64 kbps + OVER HEADS A G.729 codec produces audio compressed to 8 kbps + OVER HEADS A G.723 codec produces audio compressed to approximately 6 kbps + OVER HEADS The following table provides comparisons of several voice quality considerations associated with some codecs supported by Avaya products. Please note that toll quality voice must achieve a Mean Opinion Score (MOS) of 4 or above. MOS scoring is a long-standing subjective method of measuring voice quality.

Page 35 of 133

14 Table: Comparisons of several voice quality considerations associated with some codecs supported by Avaya products. Generally, G.711 is used within LANs because bandwidth is abundant and inexpensive whereas G.729 is used across WAN links because of the bandwidth savings and good performing voice quality. Comparison of Speech Coding Standards 1 Standard Coding Type Bit Rate (kbps) MOS G.711 PCM 64 4.3 G.729 CS-ACELP 8 4.0 G.723.1 ACELPMP-MLQ 6.3 5.3 3.8 15 BandwidthRequirements The bandwidth available to the user is very important. Access to the network using slower connections, such as dial-up connections, will degrade voice quality. The best voice quality is achieved in both LANs and WANs when the bandwidth is owned by the organization. Privately-owned bandwidth can be shaped to optimize VoIP traffic. Conversely, bandwidth that is not controlled, like the Internet, cannot give consistent sound quality because it cannot be optimized for IP telephony. Factors of delay, jitter, and packet loss are exacerbated over the Internet. Accordingly, Avaya and IPL Communication does not recommend using the Internet for voice applications at this time. OtherElementsthataffectQoS WAN Considerations Until WAN bandwidth becomes affordable at any speed, delivering bandwidth to applications over the WAN will remain a formidable task. When voice traffic is carried on packet networks, different labeling or queuing schemes function to give voice packets priority over data packets. The presence of large data packets may result in added serialization delay for VoIP packets across WAN links. This is due to the fact that smaller VoIP packets are held in queue while larger data packets are processed onto the WAN link. To avoid excessive delay, there may be benefit to fragmenting the larger data packets and interleaving them with the smaller voice packets. One technique is to adjust the packets by adjusting the Maximum Transmission Unit (MTU) size. Minimum MTU size should be no smaller than 300 bytes and no larger than 550 bytes. LAN based MTUs can be as large as 1500 bytes. It should be noted that reducing the size of the MTU will add overhead and reduce the efficiency of data applications. Other techniques, such as Multilink PPP (MPP) Link Fragmenting and Interleaving (LFI), and Frame Relay Fragmentation (FRF12) allow network managers to fragment larger packets, and allow queuing mechanisms to speed the delivery of Real Time Protocol (RTP) traffic without significantly increasing protocol overhead or reducing data efficiency. Also, header compression protocols like Compressed Real Time Protocol (CRTP) can and should be used between WAN links. Hardware based CRTP is effective with very minimal delays, but software CRTP can add significant delay. 16 Virtual Private Networks (VPNs) can use private lines or use the Internet via one or more Internet Service Providers (ISP). VPNs are implemented in both dedicated hardware and software, but can also be integrated as an application to existing hardware and software packages. A common example of an integrated package is a firewall product that can provide a barrier against unauthorized intrusion, as well as perform the security features needed for a VPN session. The encryption process can take from less than 1 milli-second to 1 second or more, at each end. Obviously, VPNs can represent a significant source of delay and, therefore, negatively affect voice performance. Also, as most VPN traffic runs over the Internet and there is little control over QoS parameters for traffic crossing the Internet, voice quality may suffer due to excessive packet loss, delay, and jitter. Users may be able to negotiate a service-level agreement with the VPN provider to guarantee an acceptable level of service. Before implementing IP telephony with a VPN, users should test their VPN network to make sure it meets all QoS requirements.

Page 36 of 133

Frame Relay Voice transported over frame relay can be subject to more delay and jitter when compared to ATM or point-to-point TDM circuits. NAT IP telephony does not work well with networks that use Network Address Translation (NAT) because most NAT implementations do not support H.323 protocols. The destination IP address is encapsulated in more than one header: the Q.931, H.225, and IP headers. NAT changes only the address in the IP header resulting in a mismatch that prohibits the control of calls. Avaya suggests using a firewall to guard against intruders, but the firewall should not provide NAT functions for VoIP packets unless it is Q.931 friendly. Conclusion The benefits of IP telephony networking for organisations are compelling, but as with most things of value, achieving these benefits requires careful preparation. Sending real-time voice messages across a connectionless IP network requires the network to deliver information with an immediacy and predictability that data networks were not originally designed to achieve. By using QoS tools, it is possible to achieve high voice quality over shared voice/data networks. To do so, network managers must condition the network to distinguish voice packets from data, and give the voice packets priority as they travel across the network. Managing the network for QoS enables organisations to achieve, in a connectionless environment, some of the performance characteristics that make circuit-switched networks effective for voice, while retaining the flexibility and economy of a converged network. These characteristics include minimal delay and the ability to prevent the entry of new data or voice-class traffic from degrading calls already in progress. Avaya networking products provide comprehensive capabilities for achieving QoS in IP networks, including IEEE 802.1p/Q standard tagging, DiffServ marking, RSVP and integrated services, dynamic jitter buffers in endpoints and network-wide policy management. Avayas standards-based approach simplifies the task of adding voice to an existing data network, and incorporating products from multiple vendors in a single solution. 22

Page 37 of 133

9, MPLS example and Configuration PLEASE NOTE THESE CONFIGURATIONS ARE CONFIGURED SPECIFICALLY FOR USE WITH THE CARRIER THAT IMPLEMENTED THIS SOLUTION, PLEASE ONLY USE THESE CONFIGURATIONS AS A REFERENCE POINT. CONNECTIONS WERE MANAGED SHDSL 512/512 INTO A MPLS CORE CONFIGURED FOR VOICE AND DATA WITH ISDN BACKUP ROUTERS WERE CISCO 828S. SERVICE WAS MANAGED END TO END. Network Diagram

Site A
Managed SHDSL

Site B
MPLS CORE MPLS Edge Router MPLS Edge Router

Backup ISDN

Cisco Routing

Cisco Routing

Site A LAN

Site B LAN

Page 38 of 133

Managed SHDSL

Site A Router Configuration.

Site_A#sh run Building configuration... Current configuration : 2295 bytes version 12.2 no service pad service timestamps debug uptime service timestamps log uptime service password-encryption hostname Site_1 ! logging queue-limit 100 logging buffered 10000 debugging no logging console enable secret <Removed> ! clock timezone EST 10 ip subnet-zero no ip domain lookup ! ip cef ! class-map match-any voice-signaling match access-group 106 class-map match-any voice-udp description Class Mapping for VoIP match access-group 101 ! policy-map voice-qos description VoIP QoS class voice-udp priority 200 class voice-signaling bandwidth 16 class class-default fair-queue ! interface Ethernet0 description Site A LAN ip address 10.10.10.254 255.255.255.0 no keepalive hold-queue 100 out ! interface ATM0 no ip address no atm ilmi-keepalive dsl equipment-type CPE dsl operating-mode GSHDSL symmetric annex B dsl linerate AUTO ! interface ATM0.3 point-to-point description Internet Network pvc 1/34 vbr-rt 512 512 1 tx-ring-limit 3 encapsulation aal5mux ppp dialer dialer pool-member 3 service-policy output voice-qos ! interface Dialer3 description Internet Network bandwidth 512 ip address negotiated service-policy output voice-qos

encapsulation ppp dialer pool 3 dialer-group 1 ppp authentication chap callin ppp chap hostname <Removed> ppp chap password <Removed> ! ip classless ip route 0.0.0.0 0.0.0.0 10.10.10.3 ip route 10.0.0.0 255.0.0.0 Dialer3 ip route 192.168.0.0 255.255.0.0 Dialer3 no ip http server ! access-list 101 permit udp any any dscp ef access-list 106 permit tcp any eq 1720 any access-list 106 permit tcp any any eq 1720 access-list 106 permit tcp any eq 1719 any access-list 106 permit tcp any any eq 1719 access-list 106 permit udp any eq 50795 any access-list 106 permit udp any any eq 50795 dialer-list 1 protocol ip permit snmp-server community <Removed> RO snmp-server enable traps tty line con 0 exec-timeout 2 0 password <Removed> login

Site B Router Configuration

Site_B#sh run Building configuration... Current configuration : 1983 bytes version 12.2 no service pad service timestamps debug uptime service timestamps log uptime service password-encryption ! hostname Site_2 ! logging queue-limit 100 logging buffered 10000 debugging no logging console enable secret <Removed> ! clock timezone EST 10 ip subnet-zero no ip domain lookup ! ip cef ! class-map match-any voice-signaling match access-group 106 class-map match-any voice-udp description Class Mapping for VoIP match access-group 101 !

policy-map voice-qos description VoIP QoS class voice-udp priority 200 class voice-signaling bandwidth 16 class class-default fair-queue ! interface Ethernet0 description Site B LAN ip address 10.10.20.254 255.255.255.0 no keepalive hold-queue 100 out ! interface ATM0 no ip address no atm ilmi-keepalive dsl equipment-type CPE dsl operating-mode GSHDSL symmetric annex B dsl linerate AUTO ! interface ATM0.3 point-to-point description Internet Network pvc 1/34 vbr-rt 512 512 1 tx-ring-limit 3 encapsulation aal5mux ppp dialer dialer pool-member 3 service-policy output voice-qos ! interface Dialer3 description Internet Network bandwidth 512 ip address negotiated service-policy output voice-qos encapsulation ppp dialer pool 3 dialer-group 1 ppp authentication chap callin ppp chap hostname <Removed> ppp chap password <Removed> ! ip classless ip route 0.0.0.0 0.0.0.0 Dialer3 no ip http server ! access-list 101 permit udp any any dscp ef access-list 106 permit tcp any eq 1720 any access-list 106 permit tcp any any eq 1720 access-list 106 permit tcp any eq 1719 any access-list 106 permit tcp any any eq 1719 access-list 106 permit udp any eq 50795 any access-list 106 permit udp any any eq 50795 dialer-list 1 protocol ip permit snmp-server community <Removed> RO snmp-server enable traps tty ! line con 0 exec-timeout 2 0 password <Removed> login

Page 39 of 133

10, IP Phones VLAN example and configurations PLEASE NOTE THE FOLLOWING CONFIGURATIONS/EXAMPLES HAVE BEEN PROVIDED AS REFERENCE MATERIAL ONLY, THESE CONFIGURATIONS HAVE BEEN TAKEN FROM A REAL INSTALLATION, WHERE THE LAN ENVIROMENT HAS BEEN CONFIGURED TO SUPPORT BOTH VOICE AND DATA USING 802.1P/Q TO SUPPORT AVAYA IP PHONES AND PROVIDE COS. THE NETWORK ABOVE CONSITS OF CISCO AND DELL ETHERNET SWITCHES CONFIGUED FOR VLAN SUPPORT AND VLAN TRUNKING, A CISCO 3620 IS PERFORMING THE WAN ROUTING AND ROUTING BETWEEN THE 10.20.80.0 AND 10.20.81.0 NETWORKS. IN THIS EXAMPLE THE DHCP SERVER HAS BEEN CONFIGURED TO SUPPORT BOTH 10.20.80.0 AND 10.0.20.81.0 VLAN SCOPES. ASIGNING THE IP PHONES TO VLAN 2 WHEN THE IP PHONES ARE BOOTED AND PROVIDING THEM WITH THE CORRECT CALL AND FILESERVER INFORMATION. THIS SITE USES A COMBANATION 0F 85 AVAYA 4620S AND 4602 AVAYA IP HANDSETS CONNECTED TO AN AVAYA IP0 412. THIS SITE IS CURRENTLY RUNNING 2.1(31) FIRMWARE.

Page 40 of 133

Network diagram
VLAN 2 10.20.81.0 VOIP
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 PowerConnect 3324 G1 CONSOLE MODE 9600, N, 8, 1 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 G2 OR STACK LNK/ACT FDX STACK ID 1 G1 RPS 4 G2 STACK

VLAN 1 10.20.80.0 DATA

2 5

3 6

Windows XP SPII Client DHCP Configured DHCP Assigned to VLAN1 10.20.80.0/24

LAVSW04 10.20.80.4 Dell PowerConnect 3324

g1

Avaya 4620 DHCP Configured DHCP Assigned to VLAN2 10.20.81.0/24 Mid-Span PDU Avaya 1152A1 PDU

10Base-T/100Base-TX

Catalyst 2950 SERIES

15 16 17 18 19 20 21 22 23 24

Fiber Link

1 SYST RPS

10

11

12

13

14

STRT UTIL DUPLXSPEED

MODE

LAVSW03 10.20.80.3 Cisco Catalyst 2950 24

10Base-T/100Base-TX
1 SYST RPS 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

25

Catalyst 2950 SERIES

STRT UTIL DUPLXSPEED

25

23

MODE

22

LAVSW02 10.20.80.2 Cisco Catalyst 2950 24 2

PowerConnect 5224
1000=GREEN 10/100=ORANGE 21 22 23 24 LNK/ACT PWR DIAG RPS CONSOLE 1 3 5 7 9 11 13 15 17 19 21 23 FDX 2 4 6 8 10 12 14 16 18 20 22 24 LNK/ACT

Avaya 4620 DHCP Configured DHCP Assigned to VLAN2 10.20.81.0/24

Windows XP SPII Client DHCP Configured DHCP Assigned to VLAN1 10.20.80.0/24

11

13

15

17

19

21

23

1 19 LAV03 10.20.80.23 2003 VOIP system: IPO Admin, Voicemail Pro and IMS

10

12

14

16

18

20

22

24

1000=GREEN 10/100=ORANGE

FDX

9600, N, 8, 1

LAVSW01 10.20.80.1 Dell PowerConnect 5224 23

20

Analogue Module Avaya IP 400

Lan 1 PRI ISDN 30 Onramp

Telstra ISDN

LAV_IPO 10.20.81.60 Avaya IP Office 412 E0/1

4E
ETH 3 ETH 2 ETH 1 LINK ACT EN ETHERNET 1 ETH 0

E0/0 10.20.80.254
W0
A/UI EN

10.20.81.254
LINK LINK ACT ACT

2E 2W

W1

AUMEL01 10.20.80.20 2003 DC DHCP, DNS, WINS

ETHERNET 0

10.20.12.20 E1/2

10.20.10.20 E1/0

LAVRT01 Cisco 3620

10.20.11.20 E1/1

DSL Modem Dlink DSL500

MPLS Network

DSL Modem Dlink DSL500

LAV02 10.20.80.22 2003 File & Print, Exchange 2003, Backup and SAV Parent

DSL Modem Dlink DSL500

Page 41 of 133

DHCP Server Scopes configured on AUMEL01 10.20.80.20 10.20.80.0 Network Data Scope, Option 176 settings

10.20.81.0 Network Voice Scope, Option 176 settings

Page 42 of 133

In concept when IP Phones boot they attach to native VLAN1 the phone pulls the option 176 from the 10.20.80.0 network scope which informs the phone via the L2QVLAN=2 to reboot into VLAN2 the phone then reboots in VLAN2 and receives an IP address in the 10.20.81.0 network and receives option 176 settings for call server address (IPO), call setup port (1719), file server address (Manager or other TFTP server), ftp server (For backing up Phone Settings to FTP server). For further information on DHCP scope option please refer to the AVAYA LAN administrators guide downloadable from www.avaya.com 46XXSettings File Only entry below to disables IR Port on 4620s SET IRSTAT 0 Core Cisco 3620 LAVRT01 Configuration
version 12.2 no service pad service timestamps debug uptime service timestamps log uptime service password-encryption ! hostname lavrt01 ! enable secret 5 WITHHELD ! username admin password 7 WITHHELD clock timezone EST 10 clock summer-time EDT recurring last Sun Oct 2:00 last Sun Mar 3:00 ip subnet-zero ! ip name-server 10.20.10.30 ip name-server 10.20.10.21 ! call rsvp-sync ! interface Loopback0 ip address 10.20.254.20 255.255.255.255 ! interface BRI0/0 no ip address encapsulation hdlc shutdown ! interface Ethernet0/0 ip address 10.20.80.254 255.255.255.0 full-duplex ! interface Serial0/0 no ip address shutdown ! interface Ethernet0/1 ip address 10.20.81.254 255.255.255.0 ip helper-address 10.20.20.20 full-duplex ! interface Ethernet1/0 ip address 10.20.10.20 255.255.255.0 load-interval 30 half-duplex ! interface Ethernet1/1 ip address 10.20.11.20 255.255.255.0 load-interval 30 half-duplex ! interface Ethernet1/2

Page 43 of 133

ip address 10.20.12.20 255.255.255.0 load-interval 30 half-duplex ! interface Ethernet1/3 no ip address shutdown half-duplex ! ip classless ip route 0.0.0.0 0.0.0.0 10.20.10.10 ip route 0.0.0.0 0.0.0.0 10.20.11.10 ip route 10.20.10.60 255.255.255.255 10.20.12.10 ip route 10.20.30.60 255.255.255.255 10.20.12.30 ip http server ! snmp-server community WITHHELD snmp-server location WITHHELD snmp-server contact WITHHELD snmp-server enable traps tty ! dial-peer cor custom ! line con 0 exec-timeout 120 0 stopbits 1 line aux 0 line vty 0 4 exec-timeout 120 0 password WITHHELD login local ! scheduler max-task-time 5000 end

10.20.80.1 Dell Power Connect 5224 Configuration LAVSW01

hostname Lavswitch01 snmp-server location Server Room snmp-server contact James Lane ! ! snmp-server community private rw snmp-server community public ro ! username admin access-level 15 username admin password 7 WITHHELD username guest access-level 0 username guest password 7 WITHHELD enable password level 15 7 WITHHELD ! vlan database vlan 1 name DefaultVlan media ethernet state active vlan 2 name voice media ethernet state active ! interface ethernet 1/1 switchport allowed vlan add 1 untagged switchport native vlan 1 switchport mode trunk switchport allowed vlan add 1-2 tagged queue cos-map 3 5 6 7 ! interface ethernet 1/2 switchport allowed vlan add 1 untagged switchport native vlan 1 switchport mode trunk switchport allowed vlan add 1-2 tagged queue cos-map 3 5 6 7 !

Page 44 of 133

interface ethernet 1/3 switchport allowed vlan add 1 untagged switchport native vlan 1 switchport allowed vlan add 2 tagged queue cos-map 3 5 6 7 ! interface ethernet 1/4 switchport allowed vlan add 1 untagged switchport native vlan 1 switchport allowed vlan add 2 tagged queue cos-map 3 5 6 7 ! interface ethernet 1/5 switchport allowed vlan add 1 untagged switchport native vlan 1 switchport allowed vlan add 2 tagged queue cos-map 3 5 6 7 ! interface ethernet 1/6 switchport allowed vlan add 2 untagged switchport native vlan 2 switchport allowed vlan remove 1 switchport forbidden vlan add 1 queue cos-map 3 5 6 7 ! interface ethernet 1/7 switchport allowed vlan add 1 untagged switchport native vlan 1 switchport allowed vlan add 2 tagged queue cos-map 3 5 6 7 ! interface ethernet 1/8 switchport allowed vlan add 1 untagged switchport native vlan 1 switchport allowed vlan add 2 tagged queue cos-map 3 5 6 7 ! interface ethernet 1/9 switchport allowed vlan add 1 untagged switchport native vlan 1 switchport allowed vlan add 2 tagged queue cos-map 3 5 6 7 ! interface ethernet 1/10 switchport allowed vlan add 1 untagged switchport native vlan 1 switchport allowed vlan add 2 tagged queue cos-map 3 5 6 7 ! interface ethernet 1/11 switchport allowed vlan add 1 untagged switchport native vlan 1 switchport allowed vlan add 2 tagged queue cos-map 3 5 6 7 ! interface ethernet 1/12 switchport allowed vlan add 1 untagged switchport native vlan 1 switchport allowed vlan add 2 tagged queue cos-map 3 5 6 7 ! interface ethernet 1/13 switchport allowed vlan add 1 untagged switchport native vlan 1 switchport allowed vlan add 2 tagged queue cos-map 3 5 6 7 ! interface ethernet 1/14 switchport allowed vlan add 1 untagged switchport native vlan 1 switchport allowed vlan add 2 tagged

Page 45 of 133

queue cos-map 3 5 6 7 ! interface ethernet 1/15 switchport allowed vlan add 1 untagged switchport native vlan 1 switchport allowed vlan add 2 tagged queue cos-map 3 5 6 7 ! interface ethernet 1/16 switchport allowed vlan add 1 untagged switchport native vlan 1 switchport allowed vlan add 2 tagged queue cos-map 3 5 6 7 ! interface ethernet 1/17 switchport allowed vlan add 1 untagged switchport native vlan 1 switchport allowed vlan add 2 tagged queue cos-map 3 5 6 7 ! interface ethernet 1/18 switchport allowed vlan add 1 untagged switchport native vlan 1 switchport allowed vlan add 2 tagged queue cos-map 3 5 6 7 ! interface ethernet 1/19 switchport allowed vlan add 1 untagged switchport native vlan 1 queue cos-map 3 5 6 7 ! interface ethernet 1/20 switchport allowed vlan add 1 untagged switchport native vlan 1 switchport allowed vlan add 2 tagged queue cos-map 3 5 6 7 ! interface ethernet 1/21 switchport allowed vlan add 1 untagged switchport native vlan 1 switchport allowed vlan add 2 tagged queue cos-map 3 5 6 7 ! interface ethernet 1/22 switchport allowed vlan add 1-2 untagged switchport native vlan 1 queue cos-map 3 5 6 7 ! interface ethernet 1/23 speed-duplex 10full no negotiation switchport allowed vlan add 1 untagged switchport native vlan 1 switchport allowed vlan add 2 tagged queue cos-map 3 5 6 7 ! interface ethernet 1/24 switchport allowed vlan add 1 untagged switchport native vlan 1 switchport mode trunk switchport allowed vlan add 1-2 tagged queue cos-map 3 5 6 7 ! interface vlan 1 ip address 10.20.80.1 255.255.255.0 ip default-gateway 10.20.80.254 spanning-tree hello-time 1 line console line vty end !

Page 46 of 133

10.20.80.2 Cisco Catalyst 2950 LAVSW02

version 12.1 no service pad service timestamps debug uptime service timestamps log uptime service password-encryption ! hostname lavsw02 ! wrr-queue bandwidth 20 1 80 0 wrr-queue cos-map 1 0 1 2 4 wrr-queue cos-map 3 3 6 7 wrr-queue cos-map 4 5 mls qos map cos-dscp 0 8 16 26 32 46 48 56 ip subnet-zero ! spanning-tree mode pvst spanning-tree portfast default no spanning-tree optimize bpdu transmission spanning-tree extend system-id ! interface FastEthernet0/1 switchport trunk allowed vlan 1,2 switchport mode trunk mls qos trust cos auto qos voip trust no cdp enable spanning-tree portfast ! interface FastEthernet0/2 switchport trunk allowed vlan 1,2 switchport mode trunk mls qos trust cos auto qos voip trust no cdp enable spanning-tree portfast ! interface FastEthernet0/3 switchport trunk allowed vlan 1,2 switchport mode trunk mls qos trust cos auto qos voip trust no cdp enable spanning-tree portfast ! interface FastEthernet0/4 switchport trunk allowed vlan 1,2 switchport mode trunk mls qos trust cos auto qos voip trust no cdp enable spanning-tree portfast ! interface FastEthernet0/5 switchport trunk allowed vlan 1,2 switchport mode trunk mls qos trust cos auto qos voip trust no cdp enable spanning-tree portfast ! interface FastEthernet0/6 switchport trunk allowed vlan 1,2 switchport mode trunk mls qos trust cos auto qos voip trust no cdp enable spanning-tree portfast

Page 47 of 133

! interface FastEthernet0/7 switchport trunk allowed vlan switchport mode trunk mls qos trust cos auto qos voip trust no cdp enable spanning-tree portfast ! interface FastEthernet0/8 switchport trunk allowed vlan switchport mode trunk mls qos trust cos auto qos voip trust no cdp enable spanning-tree portfast ! interface FastEthernet0/9 switchport trunk allowed vlan switchport mode trunk mls qos trust cos auto qos voip trust no cdp enable spanning-tree portfast ! interface FastEthernet0/10 switchport trunk allowed vlan switchport mode trunk mls qos trust cos auto qos voip trust no cdp enable spanning-tree portfast ! interface FastEthernet0/11 switchport trunk allowed vlan switchport mode trunk mls qos trust cos auto qos voip trust no cdp enable spanning-tree portfast ! interface FastEthernet0/12 switchport trunk allowed vlan switchport mode trunk mls qos trust cos auto qos voip trust no cdp enable spanning-tree portfast ! interface FastEthernet0/13 switchport trunk allowed vlan switchport mode trunk mls qos trust cos auto qos voip trust no cdp enable spanning-tree portfast ! interface FastEthernet0/14 switchport trunk allowed vlan switchport mode trunk mls qos trust cos auto qos voip trust no cdp enable spanning-tree portfast ! interface FastEthernet0/15 switchport trunk allowed vlan switchport mode trunk mls qos trust cos auto qos voip trust

1,2

1,2

1,2

1,2

1,2

1,2

1,2

1,2

1,2

Page 48 of 133

no cdp enable spanning-tree portfast ! interface FastEthernet0/16 switchport trunk allowed vlan 1,2 switchport mode trunk mls qos trust cos auto qos voip trust no cdp enable spanning-tree portfast ! interface FastEthernet0/17 switchport trunk allowed vlan 1,2 switchport mode trunk mls qos trust cos auto qos voip trust no cdp enable spanning-tree portfast ! interface FastEthernet0/18 switchport trunk allowed vlan 1,2 switchport mode trunk mls qos trust cos auto qos voip trust no cdp enable spanning-tree portfast ! interface FastEthernet0/19 switchport trunk allowed vlan 1,2 switchport mode trunk mls qos trust cos auto qos voip trust no cdp enable spanning-tree portfast ! interface FastEthernet0/20 switchport trunk allowed vlan 1,2 switchport mode trunk mls qos trust cos auto qos voip trust no cdp enable spanning-tree portfast ! interface FastEthernet0/21 switchport trunk allowed vlan 1,2 switchport mode trunk mls qos trust cos auto qos voip trust no cdp enable spanning-tree portfast ! interface FastEthernet0/22 description VOIP Voice Server (lav03) switchport access vlan 2 mls qos trust cos auto qos voip trust no cdp enable spanning-tree portfast ! interface FastEthernet0/23 description VLAN 2 Router Gateway switchport access vlan 2 mls qos trust cos auto qos voip trust no cdp enable spanning-tree portfast ! interface FastEthernet0/24 description VOIP Server (IPO) switchport access vlan 2 mls qos trust cos

Page 49 of 133

auto qos voip trust no cdp enable spanning-tree portfast ! interface GigabitEthernet0/1 switchport mode trunk mls qos trust cos auto qos voip trust no cdp enable ! interface GigabitEthernet0/2 no cdp enable ! interface Vlan1 ip address 10.20.80.2 255.255.255.0 no ip route-cache ! interface Vlan2 no ip address no ip route-cache shutdown ! ip default-gateway 10.20.80.254 ip http server ! no cdp run ! line con 0 line vty 0 4 password 7 WITHHELD login line vty 5 15 password 7 WITHHELD login ! end

10.20.80.3 Cisco Catalyst 2950 LAVSW03

version 12.1 no service pad service timestamps debug uptime service timestamps log uptime service password-encryption ! hostname lavsw03 ! wrr-queue bandwidth 20 1 80 0 wrr-queue cos-map 1 0 1 2 4 wrr-queue cos-map 3 3 6 7 wrr-queue cos-map 4 5 mls qos map cos-dscp 0 8 16 26 32 46 48 56 ip subnet-zero ! spanning-tree mode pvst spanning-tree portfast default no spanning-tree optimize bpdu transmission spanning-tree extend system-id ! interface FastEthernet0/1 switchport trunk allowed vlan 1,2 switchport mode trunk mls qos trust cos auto qos voip trust no cdp enable spanning-tree portfast ! interface FastEthernet0/2 switchport trunk allowed vlan 1,2

Page 50 of 133

switchport mode trunk mls qos trust cos auto qos voip trust no cdp enable spanning-tree portfast ! interface FastEthernet0/3 switchport trunk allowed vlan switchport mode trunk mls qos trust cos auto qos voip trust no cdp enable spanning-tree portfast ! interface FastEthernet0/4 switchport trunk allowed vlan switchport mode trunk mls qos trust cos auto qos voip trust no cdp enable spanning-tree portfast ! interface FastEthernet0/5 switchport trunk allowed vlan switchport mode trunk mls qos trust cos auto qos voip trust no cdp enable spanning-tree portfast ! interface FastEthernet0/6 switchport trunk allowed vlan switchport mode trunk mls qos trust cos auto qos voip trust no cdp enable spanning-tree portfast ! interface FastEthernet0/7 switchport trunk allowed vlan switchport mode trunk mls qos trust cos auto qos voip trust no cdp enable spanning-tree portfast ! interface FastEthernet0/8 switchport trunk allowed vlan switchport mode trunk mls qos trust cos auto qos voip trust no cdp enable spanning-tree portfast ! interface FastEthernet0/9 switchport trunk allowed vlan switchport mode trunk mls qos trust cos auto qos voip trust no cdp enable spanning-tree portfast ! interface FastEthernet0/10 switchport trunk allowed vlan switchport mode trunk mls qos trust cos auto qos voip trust no cdp enable spanning-tree portfast ! interface FastEthernet0/11

1,2

1,2

1,2

1,2

1,2

1,2

1,2

1,2

Page 51 of 133

switchport trunk allowed vlan switchport mode trunk mls qos trust cos auto qos voip trust no cdp enable spanning-tree portfast ! interface FastEthernet0/12 switchport trunk allowed vlan switchport mode trunk mls qos trust cos auto qos voip trust no cdp enable spanning-tree portfast ! interface FastEthernet0/13 switchport trunk allowed vlan switchport mode trunk mls qos trust cos auto qos voip trust no cdp enable spanning-tree portfast ! interface FastEthernet0/14 switchport trunk allowed vlan switchport mode trunk mls qos trust cos auto qos voip trust no cdp enable spanning-tree portfast ! interface FastEthernet0/15 switchport trunk allowed vlan switchport mode trunk mls qos trust cos auto qos voip trust no cdp enable spanning-tree portfast ! interface FastEthernet0/16 switchport trunk allowed vlan switchport mode trunk mls qos trust cos auto qos voip trust no cdp enable spanning-tree portfast ! interface FastEthernet0/17 switchport trunk allowed vlan switchport mode trunk mls qos trust cos auto qos voip trust no cdp enable spanning-tree portfast ! interface FastEthernet0/18 switchport trunk allowed vlan switchport mode trunk mls qos trust cos auto qos voip trust no cdp enable spanning-tree portfast ! interface FastEthernet0/19 switchport trunk allowed vlan switchport mode trunk mls qos trust cos auto qos voip trust no cdp enable spanning-tree portfast !

1,2

1,2

1,2

1,2

1,2

1,2

1,2

1,2

1,2

Page 52 of 133

interface FastEthernet0/20 switchport trunk allowed vlan 1,2 switchport mode trunk mls qos trust cos auto qos voip trust no cdp enable spanning-tree portfast ! interface FastEthernet0/21 switchport trunk allowed vlan 1,2 switchport mode trunk mls qos trust cos auto qos voip trust no cdp enable spanning-tree portfast ! interface FastEthernet0/22 switchport trunk allowed vlan 1,2 switchport mode trunk mls qos trust cos auto qos voip trust no cdp enable spanning-tree portfast ! interface FastEthernet0/23 switchport trunk allowed vlan 1,2 switchport mode trunk mls qos trust cos auto qos voip trust no cdp enable spanning-tree portfast ! interface FastEthernet0/24 switchport trunk allowed vlan 1,2 switchport mode trunk mls qos trust cos auto qos voip trust no cdp enable spanning-tree portfast ! interface GigabitEthernet0/1 switchport mode trunk mls qos trust cos auto qos voip trust no cdp enable ! interface GigabitEthernet0/2 no cdp enable ! interface Vlan1 ip address 10.20.80.3 255.255.255.0 no ip route-cache ! interface Vlan2 no ip address no ip route-cache shutdown ! ip default-gateway 10.20.80.254 ip http server ! no cdp run ! line con 0 exec-timeout 0 0 line vty 0 4 password 7 WITHHELD login line vty 5 15 password 7 WITHHELD login

Page 53 of 133

! end

10.20.80.4 Dell Power Connect 3324 Configuration LAVSW04

spanning-tree mode rstp spanning-tree forward-time 5 interface range ethernet 1/e(1-24) switchport mode general exit interface ethernet 1/g1 switchport mode trunk exit vlan database vlan 2 exit interface ethernet 1/e1 switchport general allowed vlan add 2 exit interface ethernet 1/g1 switchport trunk allowed vlan add 2 exit interface vlan 2 name Voice exit interface range ethernet 1/e(1-24) switchport general ingress-filtering disable exit interface vlan 1 ip address 10.20.80.4 255.255.255.0 exit ip default-gateway 10.20.80.254 wrr-queue cos-map 3 3 wrr-queue cos-map 4 5 qos trust dscp priority-queue out num-of-queues 2 hostname lavsw04 aaa authentication enable default line aaa authentication login default line line telnet login authentication default enable authentication default exit line ssh login authentication default enable authentication default exit line console login authentication default enable authentication default exit snmp-server location WITHHELD snmp-server contact WITHHELD

Further information regarding Cisco configurations please refer to http://www.cisco.com Further information regarding Dell power edge configurations please refer to http://www.dell.com

Page 54 of 133

11, TOS, Precedence and DSCP Explained There have been two generations of quality of service architectures in the Internet. The interpretation of the Type of Service Octet in the Internet Protocol header varies between these two generations. The Type of Service Octet is the second 8-bit byte of the Internet Protocol header.

2^0 | | | | | | | | | | | | | |

2^4 |

2^8 |

2^16 | Total Length | | | Fragment Offset

2^31 | | | | | | | Header Checksum | | |

+-------+-------+---------------+---------------+---------------+ |Version| Header|Type of Service| | Length|

+-------+-------+---------------+---+-----------+---------------+ Identification | DM| |0FF| | Time to Live | | Protocol | | |

+---------------+---------------+---+-----------+---------------+

+---------------+---------------+---------------+---------------+ Source Address | | | Destination Address | |

+---------------+---------------+---------------+---------------+

+---------------+---------------+---------------+---------------+

Page 55 of 133

First generation Precedence and type of service bits The initial definition of the Type of Service Octet looked like this:

2^7 | | |

2^6

2^5 |

2^4 | D | |

2^3 | T | |

2^2 | R | |

2^1 | C | |

2^0 | | |

+-------+-------+-------+-------+-------+-------+-------+-------+ Precedence | |

+-------+-------+-------+-------+-------+-------+-------+-------+

RFC791 gives Precedence the values in the table below

Precedence 0 1 2 3 4 5 6 7 Purpose Routine Priority Immediate Flash Flash Override CRITIC/ECP Internetwork Control Network Control

Most Precedence descriptions are obscure: they relate to message handling priorities of US military communications in the 1960s. The essence is that higher values of Precedence lead to higher levels of network service. To prevent high link utilization causing routing traffic to be lost it is traditional to use Precedence = 7 for interior routing protocols such as OSPF and RIP and to use Precedence = 6 for exterior routing protocols such as BGP. The D type of service bit is defined in RFC791. A value of 0 requests normal delay, a value of 1 requests a low delay service. The T type of service bit is defined in RFC791. A value of 0 requests normal throughput, a value of 1 requests a high throughput service. The R type of service bit is defined in RFC791. A value of 0 requests normal reliability, a value of 1 requests a high reliability service.

Page 56 of 133

The C type of service bit is defined in RFC1394. A value of 0 requests normal costs, a value of 1 requests a low cost service. Precedence and type of service field

RFC1349 also made a slight change to the definition of the Type of Service Octet, redefining it so that only
one of the D, T, R and C bits can be set. The RFC also renamed the group of bits the Type of Service Field.

2^7 | | |

2^6

2^5 |

2^4

2^3

2^2

2^1 |

2^0 | | |

+-------+-------+-------+-------+-------+-------+-------+-------+ Precedence | | Type of Service Field | |

+-------+-------+-------+-------+-------+-------+-------+-------+

Second generation Differentiated services code point The Differentiated Service Code Point is a selector for router's per-hop behaviors. As a selector, there is no implication that a numerically greater DSCP implies a better network service. RFC2474 redefined the Type

of Service Octet to be:

2^7 | | |

2^6

2^5

2^4

2^3

2^2 |

2^1 | ECT | |

2^0 | CE | |

+-------+-------+-------+-------+-------+-------+-------+-------+ Differentiated Services Code Point | |

+-------+-------+-------+-------+-------+-------+-------+-------+

The fields ECT and CE are nothing to do with quality of service. They are spare bits in the IP header used by Explicit Congestion Notification. See RFC3168 for details. As can be seen, the DSCP totally overlaps the old Precedence field. So if values of DSCP are carefully chosen then backward compatibility can be achieved.

Page 57 of 133

This lead to notions of "class", each class being the group of DSCPs with the same Precedence value. Values within a class would offer similar network services but with slight differences (perhaps differing levels of service such as "gold", "silver" and "bronze"). Classes were initially defined as: DSCP Precedence 0 8 16 24 32 40 48 56 Assured forwarding service 0 1 2 3 4 5 6 7 Purpose Best effort Class 1 Class 2 Class 3 Class 4 Express forwarding Control Control

RFC2697 defined a "assured forwarding" service. This codified the idea of "bronze", "silver" and "gold"
levels of network service above the Best Effort service. DSCP 0 8 10 12 14 16 18 20 22 24 26 27 30 32 34 36 38 40 48 56 Service Best effort Class 1 Class 1, gold (AF11) Class 1, silver (AF12) Class 1, bronze (AF13) Class 2 Class 2, gold (AF21) Class 2, silver (AF22) Class 2, bronze (AF23) Class 3 Class 3, gold (AF31) Class 3, silver (AF32) Class 3, bronze (AF33) Class 4 Class 4, gold (AF41) Class 4, silver (AF42) Class 4, bronze (AF43) Express forwarding Control Control

Of course, the IETF couldn't use "loaded" terms like Gold, Silver and Bronze to describe networks services. Apparently numbers are less loaded, so the the RFC has descriptions like "AF21" rather than "Class 2, Gold".

Page 58 of 133

The actual values of the DSCP for the Assured Forwarding service make sense once you realise that they leave the last bit of the DSCP as 0 to allow for possible future developments with the Assured Forwarding service. Expedited forwarding service

RFC2598 defined a "expedited forwarding" service. This service is designed to allow ISPs to offer a service
with attributes similar to a "leased line". This service offers the ultimate in low loss, low latency and low jitter by ensuring that there is always sufficient room in output queues for the contracted expedited forwarding traffic. The Expedited Forwarding service has a DSCP of 46. DSCP 0 8 10 12 14 16 18 20 22 24 26 27 30 32 34 36 38 40 46 48 56 Class 1 Class 1, gold (AF11) Class 1, silver (AF12) Class 1, bronze (AF13) Class 2 Class 2, gold (AF21) Class 2, silver (AF22) Class 2, bronze (AF23) Class 3 Class 3, gold (AF31) Class 3, silver (AF32) Class 3, bronze (AF33) Class 4 Class 4, gold (AF41) Class 4, silver (AF42) Class 4, bronze (AF43) Express forwarding Expedited forwarding (EF) Control Control Service Best effort

Page 59 of 133

Real world DSCPs Voice Most voice over IP implementations use Precedence = 5. Discard Cisco Systems' used DSCP = 1 in Cisco Security Advisory: "Code Red" Worm - Customer Impact to mark Code Red traffic. The traffic would later be dropped. Cisco Systems' Auto QoS Cisco Systems' use standard DSCPs for their self-configuring QoS switch ports. 802 CoS DSCP 0 3 5 2 2 1 6 7 0 26 46 18 18 10 48 Best effort Voice control (SIP, H.323) Voice data (RTP, RTSP) Better effort data Better effort Streaming video Network-layer control (OSPF, RIP, EIGRP) Link-layer control (STP, CDP, UDLD) Use

Page 60 of 133

12, Tips from the trenches on VoIP Thanks to Kenneth Percy and Michael Hommer In a voice-over-IP deployment, the hotspots aren't as obvious as you might think. The clear-cut decisions center on VoIP-specific products such as IP phones, IP PBXs and voice gateways, but weaknesses in your data network will become magnified when you introduce VoIP. The first question to ask in order to avoid some post-deployment surprises is: In what kind of shape is my existing network? Real-time voice traffic will be affected by any bottleneck on the network. A delay of 1 second in retrieving a data file from a server because of congestion might be barely noticeable to the user, but add just 50 millisec of delay on a phone call and it's the difference between high-quality and very poor-quality voice communications. Before deploying any VoIP gear, you must scrutinize your network with an audit that includes three primary considerations: Utilization and network statistics. Maximum, minimum and average metrics for bandwidth consumption, latency, jitter and packet loss should be included in your audit. In the case of bandwidth utilization, the hotspot for potential bottlenecks lies in the interswitch links that make up your backbone. Maximum bandwidth utilization should be dictated by failover considerations, says Joe Tomasello, of Foundry Networks Inc. "Uplinks should always be deployed redundantly, at least," Tomasello says. "If one link fails, the other link should be able to handle the load for both links. Therefore, utilization on a trunked Ethernet uplink, for example, should never exceed 50 percent." Latency, jitter and packet loss that would be detrimental to business-quality voice are rare occurrences on today's LANs. Where they do exist, they are usually the result of antiquated equipment (such as hubs, 10M bit/sec Ethernet switches or switches with low memory capacities) or silly mistakes. Examples would be a switch with its autonegotiation algorithm disabled, forcing all switch ports to default to 10M bit/sec half-duplex communications; or a swath of Ethernet cable that's a lot longer than 328 feet, the maximum supported Category 5 cable length for Ethernet. Check that your network latencies don't exceed 100 millisec, and maximum jitter should never be more than 40 millisec. Packet loss should be zero, but the rule of thumb for tolerable voice quality is less than 1 percent. Review of infrastructure elements. The gear that powers the network should be reviewed for necessary feature support and correct configurations. Ethernet switches that will be touched by VoIP traffic should support virtual LANs. This will allow segmentation and isolation of your voice traffic across the data network. IP-based quality of service (QoS) -- such as type of service (TOS) or Differentiated Services (Diff-Serv) -should be supported. In a large VoIP deployment, this allows prioritization of packetized voice over more delay-tolerant traffic that must travel multiple subnets in a routed environment. A few IP PBX systems also require multicast support. Next, these features should be reviewed to ensure that they're turned on, and to ascertain whether any configurations could pose problems. For example, if the Spanning Tree Protocol is enabled, changes in the Layer 2 topology could cause outages of up to 60 seconds while the updates are made to each switch's database. Estimating bandwidth requirements. Most value-added resellers and integrators have tools to help you ascertain how much voice traffic is currently carried by your voice network, both incoming and outgoing, on a per-station basis. If you prefer to arm yourself with your own Page 61 of 133

calculations, there are two places to go for guidance. The first is to your existing PBX system. Most have reporting capabilities that yield utilization information. Some are easier to get at than others, but the utilization information you need -- both station-to-station and station-to-trunk -- should be there. The second is www.erlang.com, a Web site full of calculators and tutorials on voice traffic utilization. When translating voice-utilization statistics into bandwidth requirements, we use the following rules of thumb for base, worst-case LAN bandwidth calculations. First, go with a G.711 coder/decoder (codec), because it consumes the most bandwidth and provides the best voice quality. For packetization rate -- or the amount of voice payload per VoIP packet -- assume 20 millisec, the default setting on most IP PBX systems. Using G.711 with a 20-millisec packetization rate, bandwidth utilization rounds up to 88K bit/sec per voice conversation. In calculating a worst-case, busy-hour scenario, assume that one out of every four users will be on the phone simultaneously. In a 1,000-user IP voice system, multiply 250 (for the number of concurrent conversations) by 88K bit/sec per station for an additional bandwidth requirement of 22M bit/sec on your LAN. The situation is far more complicated on the WAN. There's no single rule of thumb for calculating bandwidth per call over a WAN because consumption varies by which voice coders (vocoder) and WAN protocols are used. Among low bit-rate vocoder options, G.729a is preferable. Repeated tests in our labs confirm this codec delivers the highest voice quality. Voice Activity Detection (VAD) -- also known as Silence Suppression -- should be supported for each vocoders on the IP-PBX you select and, for purposes of calculating bandwidth, assume that it is enabled. With VoIP, speech and silence are packetized. To conserve bandwidth, VAD prevents "silence packets" from being transmitted. While the conventional rule of thumb is a 35 percent savings, our testing has seen bandwidth savings of 50 percent when VAD is used. Assume the same 20-millisec packetization rate and, again, a 4-to-1 user-to-channel ratio. For example, assume the use of frame relay as our WAN protocol, and G.729a vocoder. Plugging in the other variables outlined above, VoIP bandwidth over a frame link -- with 35 percent bandwidth savings using VAD -- rounds up to 18K bit/sec per VoIP conversation. So again, with 250 VoIP station users on the phone simultaneously as your worst case, assume you need an additional 4.5M bit/sec of bandwidth on your IP WAN. One more tip concerning WAN bandwidth is to find out if your router supports RTP header compression. The standard IP/User Datagram Protocol (UDP)/RTP header consumes 40 bytes in a packet. If supported by your router, enabling RTP header compression can reduce the header information to just 2 bytes, yielding an overall bandwidth reduction of up to 50 percent. Once you determine how much VoIP data will likely be running across your network, you can focus on the network it will be touching to accommodate it. VLANs and QoS: Gotta have it A successful VoIP deployment requires VLAN and QoS capabilities at every point on the network, necessitating more intelligence in closet switches than ever before. In a best-practices scenario, all voice traffic should be isolated on a Layer 2 VLAN dedicated to voice and signaling traffic. Switches also should support Layer 3-based QoS features, such as TOS or Diff-Serv, for prioritizing traffic through multiple subnets. This is particularly important at aggregation points within the network. QoS will ensure that the VoIP traffic gets top billing at congestion points and help to maintain low latency and jitter. Setting the exact QoS value for TOS or Diff-Serv would be handled on a case-by-case basis and would depend on what the network looks like and what other traffic might need to be prioritized.

Page 62 of 133

But prepping for voice-specific VLANs and QoS capabilities doesn't stop at your network switches. IP phone support for 802.1p/Q VLAN tagging, or the ability to "tag" packets coming out of the phone that defines membership in a particular VLAN, also is necessary. Phones should come with the ability to set TOS or Diff Serv priority bits within the packets' IP headers. The new breeds of IP phones enable "one-wire-to-the-cube" installations, supporting two-port miniswitches on the backs of the phones. The Ethernet connection from the LAN attaches to one of these switch ports. The other connects to the PC, positioning the phone directly inline between the PC and the surrounding LAN. Both data and voice, then, can access the network over the same 100M bit/sec pipe. To prevent PC traffic from overwhelming voice conversations, most phones include some kind of trafficshaping mechanism in the switch. For this reason, phones with hubs in the back -- rather than switches -are less desirable. Hubs operate at only half-duplex, minimizing bandwidth to the cube, and they cannot implement QoS. Inline power over Ethernet: Gotta get it In a VoIP environment, you can look to good old Ethernet to provide an important new functionality over and above a data link delivering power inline to IP phones. There are essentially two options for delivering power over Ethernet. First is to purchase Ethernet switches that deliver data and power. Avaya Inc. and Cisco Systems Inc. are examples of vendors that sell Ethernet switches with inline power. The second is to provide midspan power insertion devices called "power hubs." Most power hubs are OEMed from the Israeli firm PowerDsine Ltd. Ethernet cable runs from the cubicles are connected to the power hubs, which are patched to the Ethernet switch. So a 48-port power hub, for instance, will power 24 IP phones. Most IP phone interfaces are "power aware" to receive power via the Ethernet connection. Power is sent over the unused pairs of a Cat 5 cable or over the same pairs (phantom power) used for data, in which case the Ethernet power sources employ a detection algorithm to determine whether to send power to a connected interface. Those few IP phones today that do not have power-aware Ethernet interfaces can use a power hub and maintain the one wire to the desktop. They usually ship with special line splitters, or "pig tails." These line splitters have a female RJ-45 connector on one end to receive the powered Ethernet, branching out into two prongs. One is a DC power connector for the phone, the other is a male RJ-45 Ethernet connection to the phone. Power is effectively "peeled off" the incoming Ethernet connection and sent to the phone's DC power jack. The data goes to the Ethernet port. Determining whether powered switches or mid-span insertion is better is a matter of cost. If you need more switches, or those you have need replacing, you might as well go with powered switches. Because power failure to your Ethernet switches will leave your company unable to communicate via voice or data, back-up power for your Ethernet switches should be closely examined. Legacy digital phones sets are terminated at the PBXs, so UPSs for the PBX protect the phones and the PBX. IP station connections terminate at the Ethernet switches. If power to the switch is lost, loss of both voice and data could occur. Upgrading UPSs to prevent longer blackouts also might become necessary. The ratio of necessary switches to UPSs depends on the size of the UPS. Most major UPS vendors provide resources to determine which model UPS a user should get based on the load and the duration of coverage.

Page 63 of 133

Security: Gotta foil eavesdroppers Security issues have always been a standard refrain for VoIP detractors, and with good cause. Lest we forget, VoIP is data, with all its vulnerabilities. But, while security at the network's edge is always the prevalent concern, we also warn that you have to look inside for security concerns with a VoIP deployment. Treat your IP-based PBX with at least the same diligence as you would any mission-critical server. Defining VLANs and enabling security features on the switch that map specific media access control addresses to specific ports is a good start. In large implementations, install a dedicated internal firewall to protect the PBX. Perhaps the most dreaded form of deviant behavior facilitated by a VoIP platform is eavesdropping. TDM based PBXs sit on physical isolated networks, and they use highly proprietary digital signaling. While conversations can be tapped and recorded, both require physical access to the PBX or physically splicing phone lines. With VoIP, off-the-shelf packet sniffers can capture conversations and not only replay them, but also store and distribute them as electronic files. VoIP equipment vendors are beginning to add security features to encrypt media streams. For example, on its S8700 Media Server and G600 Media Gateway, Avaya has added Media Encryption on an active IP call. When nonauthenticated users attempt to intercept the packets, they hear white noise when replayed. While it obviates the economies converged networks can produce, some IT administrators take security concerns so far as to run parallel physical networks for voice and data rather than run both across the same links. Customers with the budget for it can achieve the best of all worlds from a security point of view. But this option is expensive, and tight security can be achieved with a well-conceived deployment. The edge: Gotta get around NAT An important fundamental aspect of VoIP is that there are two different data paths: the signaling path and the voice path. When a PBX-attached IP phone goes off-hook, it signals the start of a call-setup process. In most IP PBX systems, the back-end call server will set up, tear down and peripherally monitor call states. But the packetized voice conversation occurs directly between the endpoints (peer-to-peer) without further back-end intervention. This characteristic makes network address translation (NAT) a troublesome proposition because signaling comes from one network node (the call server), and the media stream comes from another (IP phone). This problem is compounded because NAT functions at Layer 3. Peer-to-peer voice communications occur via the Real-Time Protocol (RTP), which embeds the source and destination IP addressing in the Layer 7 headers, rendering the return data address inaccessible to any NAT engine. Stateful firewalls are equally problematic. Outbound VoIP communications create "pinholes" through the firewall to allow outbound voice communications. However, inbound voice data will attempt to enter the network using different socket information than the signaling data used, and the firewall will consequently block the RTP stream. Furthermore, creating pinholes for all the possible port ranges negotiated by the endpoints defeats the firewall's purpose. One possible solution is a VoIP-aware firewall, which adds application-proxy functionality to base firewall products that enable dynamic opening and closing of firewall ports on a connection-by-connection basis. This functionality can be added via upgrades to an existing firewall product, or via third-party hardware that resides logically alongside the firewall, such as those offered by Jasomi Networks Inc. and Kagoor Networks Inc. You also can take a VPN route to support VoIP between sites or for remote access because VPNs circumvent NAT and firewall issues by tunneling. Site-to-site VPN links are becoming more common. If you're considering one, using it to link your PBX network should be added to the plus column. However, the

Page 64 of 133

gotchas with VPNs that you should beware of include bandwidth and latency. The overhead and delay encryption adds should be taken into account for optimal planning. Planning makes perfect While VoIP can ride over the highways as our data currently does, it is a new application with new rules. Deciding on the right VoIP solution is just the beginning; deploying it on the network properly is the real task. Knowing your network, ensuring the quality of your voice traffic, making sure your network and personnel infrastructures are up to the task and properly protecting your IP PBX will help your deployment be successful. -- Network World US Percy is a technology analyst and Hommer is manager of consulting services for Miercom, a network consultancy in Princeton Junction, N.J. They can be reached at kpercy@miercom.com and mhommer@miercom.com. Kenneth Percy and Michael Hommer

Page 65 of 133

13, General Protocol Information Data Link Layer 2 - Frame Relay Frame Format

Flag
1 Byte 1 Byte DLCI C/R EA

Header
DLCI 1 Byte Fecn Becn DE EA

Data
Variable

FSC
2 Bytes

Flag
1 Byte

8-3

8-5

Flag: Contains value of 0x7E (0111 1110) which indicates the start and end of each frame. Sometimes it is actually 2 Bytes. DLCI: Data Link Connection Identifier (10 bits) C/R: Command/Response field bit EA: Extended Address bit (usually not used) FECN: Forward Explicit Congestion Notification BECN: Backward Explicit Congestion Notification DE: Discard Eligibility Indicator FCS: Frame Check Sequence. Used locally to check that the frame has been received without errors. Total Overhead: 6 Bytes (Header + Trailer)

BW = (FR Header + IP + UDP + RTP + G.7xx Sample + FR Trailer) x 8 / Sample Rate

Page 66 of 133

Data Link Layer 2 - PPP in HDLC-Like Framing

Flag Address
1 Byte 1 Byte

Header Control
1 Byte

Data Protocol
2 Bytes Variable

FCS
2 Bytes

Flag
1 Byte

Flag: Contains value of 0x7E (0111 1110) indicates the start and end of each frame. Only one Flag is required between two frames. Address: Address field which contains the value of 0xFF (1111 1111), the All-Stations address. Individual station addresses are not assigned, so this field is always 0xFF Control: Value is always 0x03 (0000 0011). This value is the HDLC command for UI (Unnumbered Information) with the Poll/Final bit set to zero Protocol: Identifies the datagram encapsulated in the Data field of the packet. For IP the value is 0x0021 (0000 0000 0010 0001) FCS: Frame Check Sequence. Used locally to check that the frame has been received without errors.

Total Overhead:

8 Bytes

(Header + Trailer)

BW = (PPP Header + IP + UDP + RTP + G.7xx Sample + PPP Trailer) x 8 / Sample Rate Note: Although a PPP frame has two flags, when frames are coming in sequence (one right after the other one) the END flag of one frame is actually used as the START flag of the next frame, which means we should only be counting 7-Byte overhead instead of 8. If we were to send a single frame we would need the two flags. When two flags arrive together the system assumes there was an empty frame. I'm using 8-byte in the formulas just to take the worst scenario.

Page 67 of 133

Data Link Layer 2 - ATM Cell & AAL 5 AAL CS PDU Information
1-48 Bytes

PAD
0-47 Bytes

UU
1

CPI
1

Length
2 Bytes 8 Bytes Trailer

CRC-32
4 Bytes

Information: Variable length field that contains the user information PAD: Padding use to cell align the trailer so the whole thing is a multiple of 48-Bytes UU: CPCS user-to-user indication to transfer one byte of user information CPI: Common part indicator is a filling bit (of value 0) Length: Length of the information field CRC-32: Cyclic Redundancy Check

AAL5 SAR PDU

Payload
48 Bytes

AAL5, also known as Simple and Efficient Adaptation Layer (SEAL), is the most common adaptation layer used in ATM. The purpose of the two AAL sub layer is to covert the user data into 48-Byte data so they fit into the ATM cell. The unit of data produce at this layer is a protocol data unit (PDU) Convergence Sub layer (CS): responsible for dividing data from the next higher layer into logical packet data units (CS-PDU) that are usable by the SAR sub layer. Segmentation and Reassembly Sub layer (SAR): Responsible for the segmentation of CS-PDU information into 48-Bytes fields suitable for the payload of ATM cells.

Page 68 of 133

ATM CELL GFC

4 bits

VPI
1 Byte

VCI
2 Bytes 5 Bytes Header

PT
3 bits

CLP
1 bit

HEC
1 Bytes

Data
48 Bytes

GFC: Generic Flow control (000 = uncontrolled access) VPI: Virtual Path Identifier VCI: Virtual Channel Identifier PT: Payload type CLP: Cell Loss Priority HEC: Header Error Control

BW = ([Cells per sample x 53] x 8) / Sample Rate

Cells per sample = (G.7xx Sample + IP + UDP + RTP + 8[byte aal5 OH]) / 48

(round up to whole number)

Page 69 of 133

Data Link Layer 2 Ethernet II and 802.3 Frame Format

Preamble
8 Bytes

DA
6 Bytes

SA
6 Bytes

Type
2 Bytes

Data
46-1500 Bytes Variable

FCS
4 Bytes

Preamble: Start indicator that has a special bit pattern which alerts devices of the beginning of a data frame DA: Destination MAC Address SA: Source MAC Address Type: Specifies the upper layer protocol that will receive the data. For IP the value will be: 0x0800 (0000 1000 0000 0000) If using 802.1p/Q then value will be: 0x8100 (1000 0001 0000 0000) FCS: Frame Check Sequence

Total Overhead:

26 Bytes

(Header + Trailer)

Data Link Layer 2 Ethernet II and 802.3 with 802.1p/Q Frame Format

Preamble
8 Bytes

DA
6 Bytes

SA
6 Bytes

Type
2 Bytes 3 (81 00h) P 1 CFI

TCI
2 Bytes 12 VLAN ID

Data
46-1500 Bytes

FCS
4 Bytes

Variable

TCI: Tag Control Information P: 3-bits Priority. Range from 0 to 7 CFI: 1-bit to specify the tunnel type. For Ethernet this bit is 0 VLAN ID: 12-bits VLAN ID.

Total Overhead:

28 Bytes

(Header + Trailer)

BW = (Ethernet Header + IP + UDP + RTP + G.7xx Sample + Ethernet Trailer) x 8 / Sample Rate

Page 70 of 133

Network Layer 3 IP Packet Version 4 Format IP 1 Byte

32-bits 1-4 5-8 9 - 16 17 -24 25 - 32

Data 1 Byte 1 Byte

1 Byte

Version

IHL Identification

TOS

Time to Live

Protocol Source Address Destination Address Options (+ padding)

Total Length Flag | Fragment Offset Header Checksum

Variable

Version: Indicates the version of this IP datagram IHL: IP Heather Length - Indicates the datagram header length in 32-bit words TOS: Type Of Service Total Length: Length of the datagram measured in bytes, including the IP header and data Identification: Identifying value assigned by the sender to aid in assembling the fragments of a datagram Flag: (3-Bit) Control flag Bit 0 is reserved and must be zero. Bit 1: Dont fragment bit: 0 May fragment, 1 Don't fragment Bit 2: More fragments bits: 0 Last fragment, 1 More fragment Time to Live: Indicates the maximum time the datagram is allowed to remain in the Internet system Protocol: Indicates which upper layer protocol receives incoming packet Header Checksum: A checksum on the header only Source Address: Specifies the sending node Destination Address: Specifies the receiving node Options: Allows IP to support different options, such as security It may or may not appear in datagrams. They must be implemented by all IP modules (host and gateways).

Page 71 of 133

Network Layer 3 IP Security (IPSec) ESP in Tunnel Mode with DES or 3DES ESP Header
SPI Sequence number

Payload
Initialization Vector (IV) Data (encrypted payload) [variable]

ESP Trailer
Padding (variable) Pad Length Authentication Data Authentication Data 1 Byte Authentication Data 1 Byte 1 Byte 32 bits 1 Byte Next Hdr

1 Byte

1 Byte

1 Byte 32 bits

1 Byte

8 Bytes 64 bits

SPI: 4 bytes. An arbitrary value that, in combination with the destination IP address and security protocol (ESP), uniquely identifies the SA for this datagram Sequence Number: 4 bytes (unsigned). This field contains a monotonically increasing counter value Padding: Variable Length from 0 to 7 Bytes Pad Length: 1 byte. Specifies the size of the Padding field in bytes. Next Header: 1 byte. Protocol number that describes the format of the Payload Data field. Authentication Data: 12 bytes. Contains the ICV (Integrity Check Value) computed over the ESP packet minus the Authentication data. (HMAC-SHA1-96 or HMAC-MD5-96, RFC2404) Payload: ESP payload is made up of the IV (8 Bytes) followed by the raw cipher-text data (variable length) Full IPSec packet traveling on the network IP Header ESP Header ESP Payload (VoIP Packet) ESP Trailer Authentication Data

Padding, PadLenght, NextHr

Authenticated Data Encrypted Data (Header + IV + Trailer) and assuming 7 Bytes Padding (New IP packet + ESP packet)

Total ESP Overhead: Toal Overhead:

37 Bytes 57 Bytes

BW = (IP + ESP header + IV + VoIP packet + ESP trailer) x 8 / Sample Rate VoIP packet = IP + UDP + RTP + G.7xx Sample

Page 72 of 133

Full IPSec packet traveling on the network with UDP encapsulation IP Header UDP Header ESP Header ESP Payload (VoIP Packet) ESP Trailer Authentication Data

Padding, PadLenght, NextHr

Authenticated Data Encrypted Data (Header + IV + Trailer) and assuming 7 Bytes Padding (New IP packet + UDP + ESP packet)

Total ESP Overhead: Toal Overhead:

37 Bytes 65 Bytes

BW = (IP + UDP + ESP header + IV + VoIP packet + ESP trailer) x 8 / Sample Rate VoIP packet = IP + UDP + RTP + G.7xx Sample

Page 73 of 133

Transport Layer 4 TCP Packet Format TCP 1 Byte

1-4 5 - 10 11 12

Data 1 Byte 1 Byte

17 - 32

1 Byte
32-bit 13 14 15 16

Variable

Source Port Sequence Number Acknowledgement Number Resrvd U A P R S F Checksum Option (+ Padding)

Destination Port

Offset

Window Urgent Pointer

Source Port: Source port number Destination Port: Destination port number Sequence: The sequence number of the first data octet in this segment (except when SYN is present). If SYN is present, the sequence number is the initial sequence number (ISN) and the first data octet is ISN+1. Each byte of data is assigned a sequence number. The first byte of data by a station in a particular TCP header will have its sequence number in this field, say 58000. If this packet has 700 bytes of data in it then the next packet sent by this station will have the sequence number of 58000 + 700 + 1 = 58701 Acknowledgement: If the ACK control bit is set, this field contains the value of the next sequence number which the sender of the segment is expecting to receive. Once a connection is established this value is always sent. Data Offset: 4 bits used to indicate where the data begins (this field is also known as HLEN) Reserved: 6 bits reserved for future used (must be zero) Control bits: U (URG) Urgent Pointer field significant A (ACK) Acknowledgement field significant P (PSH) Push function R (RST) Reset the connection S (SYN) Synchronize sequence numbers F (FIN) End of data Window: 16 bits. Indicates the number of data octets which the sender of this segment is willing to accept (beginning with the octet indicated in the Acknowledgement field Checksum: 16 bits Urgent Pointer: 16 bits used to communicate the value of the current pointer as a positive offset from the sequence number in this segment. It can only be interpreted in segments for which the URG control bit has been set. Options: May be transmitted at the end of the TCP header and it always has a length which is multiple of 8 bits

Total Header:

12 Bytes

(Assuming there isn't CSRC)

Page 74 of 133

Transport Layer 4 UDP Packet Format UDP 1 Byte

1 - 16

Data 1 Byte 1 Byte

17 - 32

1 Byte
32-bits

Variable

Source Port Length

Destination Port Header Checksum

Source Port: Source port is an optional field. When used, it indicates the port of the sending process Destination Port: Destination port has a meaning within the context of a particular Internet destination address Length: The length in octets of this user datagram, including this header and the data Header Checksum: A checksum on the header only

Total Header:

8 Bytes

Page 75 of 133

Transport Layer 4 RTP Packet Format RTP 1 Byte

32-bits 1 2 3 4 V P X 5-8 CRSC count 9 M 10 - 16 Payload Type Timestamp SSRC 17 - 24 25 - 32

Data 1 Byte 1 Byte Variable

1 Byte

Sequence Number

CSRC (0 - 60 bytes) V: Identifies RTP version P: Padding. When set, the packet contains one or more additional padding octets at the end which are not part of the payload X: Extension bit. When set, the fixed header is followed by exactly one header extension with a defined format CSRC Count: Contains the number of CSRC identifiers that follow the fixed header M: Marker. Allows significant events such as frame boundaries to be marked in the packet stream Payload Type: Identifies the format of the RTP payload and determines its interpretation by the application Sequence number: Increments by one for each RTP data packet sent Timestamp: Reflects the sampling instant of the first octed in the RTP data packet SSRC: Identifies the synchronisation source. This identifier is chosen randomly. CSRC: Contributing source identifier list (Optional) Total Header: 12 Bytes

(Assuming there isn't CSRC)

Page 76 of 133

14, VoIP Mean Opinion Scores Media Encoding Overview Compression Scheme G.711 G.726 G.728 G.729 G.723 PCM ADPCM LD-CELP CD-ACELP MP-MLQ Sampling Rate (KHz) 8 8 8 8 8 Bit Rate (kbps) 64 16, 24, 32, 40 16 8 5.3, 6.4 Frame Size (ms) 10 10 10 10 30 Required CPU Resources Non Req Low Very high High Moderate Voice Quality Excellent Good (40) Fair (24) Good Good Good (6.4) Fair (5.3) Excellent (64) Excellent (56) Good (48) Excellent (24) Excellent (32) Delay (Lookahead) 0 ms 0 ms 0 ms 5 ms 7.5 ms

MOS 4.3 - 4.7 3.9 3.7 3.7 3.92 4.2 3.8 - 4.0 3.5 - 3.7

G.722

SB-ADPCM

16

48, 56, 64

10

Low

4.5 4.3 3.8

1.5 ms

G.722.1

Transform Coding (MLT)

16

24, 32

20

High

4.2 4.2

20 ms

Mean Opinion Scores (MOS) Opinion Scale Score 5 4 3 2 1 Conversation Test Excellent Good Fair Poor Bad Listening Test Excellent Good Fair Poor Bad Listening Effort Scale
Complete relaxation possible, no effort required Attention required necessary, no effort

Loudness Preference Scale

Much louder than preferred Louder than preferred Preferred Quieter than preferred Much quieter than preferred

Moderate effort required Considerable effort required No meaning understood with any feasible effort

Note: Because the quality of the transmitted speech is subjective to the users, there is a common benchmark people use to determine the quality of sound for a given codec. This benchmark is based on the ITU-T recommendation P.800 and it is called MOS. Users are presented with preselected voice samples they have to rate so at the end of the test all scores get converted to a single MOS value.

Page 77 of 133

15, Internet throughput description The purpose of this section is to provide some insight into the throughput possible on DSL services. Take an example below outlining a 2Mb connection 2Mb DSL Service the available Bandwidth is = to 2000 kbps (kiliobits per second (kbps)) On a 20000 kbps connection - the theoretical available throughput is equal to 200KBps (KiloBytes per Second (KBps)) The calculation is provided below 2000/10 = 200 We divide by 10 because Even though there are 8 bits in every byte, the nature of asynchronous transmission (used by most connection methods for accessing the Internet) requires the receiving of two "dead" bits for every 8 bits of useful data transferred: the start and stop bits. Bottom line, it takes 10 bits of transmission horsepower to deliver 8 bits of useful information. The question this begs is, how much data actually moves from one place to another in a given amount of time. And that's the definition of throughput. Other factors also have an effect on throughput, things like packet loss, data compression, line quality, and server load. The very essence of asynchronous data transfer is that it is very flexible, able to deal with variations in performance. That's why throughput is an inexact science, and why the table shows guesstimates only, which use the "divide by 10" method. Some people say it's more proper to divide by 9, but in my experience, something more like 12 might come closer to approximating what people actually see on an ideal basis. Still, I've chosen to divide by 10 because that's the number most people consider the best one. In the end, you'll have to make your own judgment. For a more detailed explanation refer to http://www.scotsnewsletter.com/best_of/dtrct.htm 10 Mb Connection example If you analyse the properties 10Mb connection we should observe the following 10Mb is in fact meaning the interface / connection is able to process 10,000 kbps (kilobits per second). To work out the available throughput you should be seeing on average we use the following 10000 / 10 equals 1000 KBps (KiloBytes per Second) or 1MB (one megabyte per second) If we divide by 8 without knowing the 10 rule which most people do you would see 1250KBps or in 1.2MB available throughput. A Web Browser for example IE displays the throughput being provided to the program as KiloBytes per second or if the speed is fast enough it shows Mega Bytes per Second.

Page 78 of 133

16, IP Office SCN (Small Community Network) Supported Configurations IP Office systems linked by IP trunks can have Small Community Networking (SCN) enabled. Using SCN, the separate IP Office systems 'learn' each other's extension numbers and user names. This allows extension calls between systems and support for a range of internal call features. IP Office Small Community Networking currently supports a maximum of 500 extensions across up to 16 IP Office systems. To set up a small community network, the following are required: A working IP trunk between the IP Office systems that has been tested for correct voice and data traffic routing. For Small Community Networks of more than two IP Office systems, a star network configuration is recommended. VCM modules are required in all systems. The extension and group numbering on each system must be unique. The extension and group names on each system must be unique. We also recommend that all names and numbers (groups, line, services, etc) on the separate IP Office systems are kept unique. This will reduce potential maintenance confusion. All systems should use the same set of Telephony timers, especially the Default No Answer Time.

Supported Network Layouts The IP Office systems within a Small Community network should only be connected in a star and or serial layout. For each IP Office there should only be one possible route to any other IP Office even if that route is via intermediate IP Offices. The following are examples.

The use of 'mesh' layouts connections is not supported. That is connections where more there are more than one possible route between any two IP Offices.

Page 79 of 133

Small Community Network Features The features supported across a Small Community Network are: User buttons. Camp-on. Call Back When Free. Paging. Call Pick-up. Internal Directory. Absent Text Message. Anti-Tromboning. Centralized Voice Mail using Voicemail Pro. Within a Small Community Network, a single Voicemail Pro can be used to provide voicemail services for all the IP Office systems. For full details of installation and setup refer to the Voicemail Pro documentation. The Voicemail Pro is licensed and hosted by a chosen central IP Office system and provides full operation for that system. Queuing on remote systems is not supported. The voicemail features supported for the other remote IP Offices are: User mailboxes. Call recording. Dial by Name. Auto Attendants. Breakout (requires that the numbers used are routable by the system hosting the Voicemail Pro).

Page 80 of 133

17, VLAN Suggestion Diagrams Always consult a network engineer who is familiar with the existing network setup prior to implementing a solution. A full audit of existing and proposed equipment must be completed to confirm adherence to standards such as 802.1pq. If implementing on an existing Cisco VLAN environment make sure of the exact VLAN Tagging being performed some VLAN Tagging mechanisms are proprietary to Cisco eg: ISL, hence in some cases cannot be used with out brands of switches. Please Note the IP office must always reside in the Data VLAN (or where the Client PCs are located) This is due to the fact the IP office uses Broadcast traffic for Phone Manager updates, Routers Drop broadcast packets hence BLF updates do not work, if not in the same VLAN.
We simply provide these examples to visually reflect the different ways that VLANS can be implemented in customer site. The examples are basic and use generic IP addressing and VLAN details. Again always consult a network engineer who is familiar with the existing network setup prior to implementing or selling a IP Phone solution.

Example 1
Preferred If PCs are not connected to IP Telephones 10.10.11.0 DATA SUBNET

Upstream Network

Requires 1 Ethernet Interface on Router

Sub Interface programmed and ability for 1.q trunk on router

10.10.10.0 10.10.11.0

X
.1q Trunk

Ports Statically configured in VLANS. DHCP Helper Required

VLAN 10 DATA CLIENT DEVICES / PRINTERS

IP412 Office
EXPANSION PORTS 1 2 3 4 5 6 7 8 9 10 11 12 W AN 1 1 TRUNK PORTS 2 3 4 5 6 7 8 1 LAN 2

VLAN 11 VOICE

10.10.10.10.0 VOICE SUBNET

PHONE/EXIT PAG E LE FT P AGE R IG HT O PTIO NS S PEA KER H OLD

H EAD SET

TRANSFER

0SW IP

MUTE

ABC

DE F

1
GH I JKL

2
MNO

3 6
DRO P

CONFERENCE

4
P Q RS TU V

5
W XYZ

8 0 #

R EDI AL

.1q Trunk

IP Office 406V2 IP500

VLAN 10 DATA

VLAN 11 VOICE

AVAYA Handset NO PC Attached to LAN Interface

Support for many more Data VLANS if required

Example 2

Upstream Network

Requires 2 Ethernet Interfaces on Router

Ports Statically configured in VLANS, No need to a .1q trunk to router. DHCP Helper Required

10.10.11.0

10.10.10.0

10.10.11.0 DATA SUBNET CLIENT DEVICES / PRINTERS

IP412 Office
1 2 EXPANSION PORTS 3 4 5 6 7 8 9 10 11 12 WAN 1 TRUNK PORTS 1 2 3 4 5 6 7 8 1 LAN 2

VLAN 10 DATA

VLAN 11 VOICE

10.10.10.10.0 VOICE SUBNET

PHONE/EXIT

PAG E LE FT

P AGE R IG HT

O PTIO NS

S PEA KER

H OLD

H EAD SET

TRANSFER

0SW IP

MUTE

ABC

DE F

1
GH I JKL

2
MNO

3 6
DRO P

CONFERENCE

4
P Q RS TU V

5
W XYZ

8 0 #

R EDI AL

.1q Trunk

IP Office 406V2 IP500

VLAN 10 DATA

VLAN 11 VOICE

AVAYA Handset NO PC Attached to LAN Interface

Support for many more Data VLANS if required

Page 81 of 133

PHONE/ EXIT

P AGE LEF T

P AGE RIGHT

OP T ONS I

S PE AKER

HOLD

HEADSE T

TRANS FER

0SW IP

M E UT

ABC

D EF

1
GH I J KL

2
MNO

3 6
DROP

CONFERENCE

4
PQ RS TUV

5
WX YZ

8 0 #

REDIAL

IP412 Office

E XPANSION PORTS 1 2 3 4 5 6 7 8 9 10 11 12

WA N 1

TRUNK PORTS 1 2 3 4 5 6 7 8

LAN

PHONE/ EXIT

P AGE LEF T

P AGE RIGHT

OP T ONS I

S PE AKER

HOLD

HEADSE T

TRANS FER

0SW IP

M E UT

ABC

D EF

1
GH I J KL

2
MNO

3 6
DROP

CONFERENCE

4
PQ RS TUV

5
WX YZ

8 0 #

REDIAL

IP412 Office

E XPANSION PORTS 1 2 3 4 5 6 7 8 9 10 11 12

WA N 1

TRUNK PORTS 1 2 3 4 5 6 7 8

LAN

Page 82 of 133

18, SIP Sample Configurations and Australian Test Results During the 4.0 field trials in Late 2006 we conducted some testing with an IP 500 base unit with a VCM 32 Card, SIP Licences configured to use four SIP carriers based in Australia. The carriers we conducted testing with were

MyTel http://www.mytel.net.au

Soul Australia http://www.soul.com.au

ISPhone http://www.isphone.com.au

Engin http://www.engin.com.au We simply provide this document to help with the configuration to the carriers above. However the documented settings will help you in configuring to any SIP carrier regardless if they require authentication or not, the IP Office 4.0 supports both. In all the configs we used ARS (Alternate Route Selection), You are able to configure many concurrent carriers with unique Line Group ID,s using different ARS Short codes to route the calls based on cost of call. The tests and procedures were conducted on an IP Office 500 Firmware 4.0(38) connected directly to the public Internet via WAN port with IP Address of 211.27.21.53/29. LAN1 was connected to the 200.0.0/24 network for management purposes. No NAT or Firewalls were present on the external WAN interface, these tests were simply to confirm connectivity and feature set. The setting and test results were correct at time of writing this document, we will not be held responsible if these settings are no longer correct, or you are unable to connect to the carrier outlined in this document.

Page 83 of 133

The following test scenarios were conducted with all four carriers. Mytel IPO Outbound PSTN
Call ringback: Voice cut through on connect G.729a Ringback terminated on caller disconnect long duration call: 1 hour DTMF relay Called party disconnect; calling party automatically disconnected Calling party disconnect; called party automatically disconnected

Engin X X X X X X

ISPhone X X X X X X X X X X X X X X

Soul X X X X X X X X X X X X X X X X X X X X X X X X X X x 2 2 X*

X X X X X X X X X X X X X X X

PSTN inbound to IPO

Call ringback: Voice cut through on connect Ringback terminated on caller disconnect long duration call: 1 hour DTMF relay Called party disconnect; calling party automatically disconnected Calling party disconnect; called party automatically disconnected

IPO Conference Call

Digital IPO Phone to PSTN Hold Phone2 Hold PSTN Phone all Conference Digital IPO Phone to Digital IPO Phone Internally conference in PSTN User PSTN to Phone1 Hold Call IPO Digital Phone2 Conference

X X X

X X X X X

PSTN to Voicemail
PSTN to IPO: retrieve voice mail PSTN to IP IPO: leave voice mail

X X X X X X X X X X 2 2 X X

Call Hold and Resume

IPO to PSTN PSTN to IPO

X X X X X X X x 2 2 X

IPO to Dell Support 1800816818 - 1-2-1-2-7

Call ringback: Voice cut through on connect to initial voice prompt Interact with voice prompt using DTMF for as long as possible (more than 30 seconds) Calling party disconnect; called party automatically disconnected (verify with ethereal trace)

X X X X X

Voice Quality
IPO to PSTN Inbound to IPO

Simultaneous Calls (Minimum 2)

IPO to PSTN Inbound to IPO PSTN to IPO (CLI Presented) * Can be enabled on a different service that Soul Offer

Page 84 of 133

See below detailed information regarding the IP 500 Configuration Basic Network Diagram

LAN1 Settings

LAN2 (WAN Port) Settings

Page 85 of 133

LAN2 Gatekeeper Settings

LAN2 STUN Settings

See below License Valid and Control Unit Used

Page 86 of 133

MyTel Configuration The testing was conducted on 4.0 Pre Release Notes: MyTel do not require the number to be presented to them in International format MyTel SIP account can be accessed from any public accessible device Details we were given from the carrier "SIP Server" to gw02.mytel.net.au "Registration Server" set this to gw02.mytel.net.au "SIP User ID" (and "Authenticate ID" too, if it's there) to 357108 "Display Name" to Scott Hayman "Password" to XXXX (Hidden for Security Reasons) Set the preferred codec to GSM or G729a In-dial Number on Service 02 90372208 These relate to the following fields in the IP Office 4.0 Config "SIP Server" to gw02.mytel.net.au and "Registration Server" set this to gw02.mytel.net.au IPO FIELD = ITSP IP Address - 203.166.130.242

The IP Office does not have the ability to resolve DNS addresses so you have to enter the IP Address, Note however if the carrier updates the SIP Server in DNS to refect a different IP Address your calls will fail and the ITSP field will need to be reconfigured to reflect the new Server IP Address. You can obtain the IP address of the DNS entry by using NSLOOKUP in Windows command prompt.
Set "SIP User ID" (and "Authenticate ID" too, if it's there) to 357108 IPO FIELD = Primary Authentication Name: 357108 Set "Password" to XXXX (Hidden for Security Reasons) Primary Authentication Password: XXXXXX (Hidden for Security Reasons) If possible, set the preferred codec to GSM or G729a IPO FIELD - Compression Mode: G.729(a) CS-ACLEP Set this field to G.729(a) CS-ACLEP The IP Office does not support GSM Codecs IPO FIELD - Registration Required: Ticked IPO FIELD - In Service: Ticked IPO FIELD - Primary Registration Expiry: 60 but could be 3600 depending on how often you wish to refresh your registration.

Page 87 of 133

See below Screen Shot of the SIP Line 10

We gave the Line Incoming and Outgoing Group 249 All Local URI, Contact and Display names were set to Use Authentication Name

Page 88 of 133

See below ARS configuration including SIP Short code for 9 numbers

INCOMING CONFIGURATION See below Incoming call route directed to Extension 210 for Incoming Line Group 249

Page 89 of 133

See below Sys-Monitor trace of Extension 210 to 96677152 via SIP Line 249 as per ARS settings.
2050891mS PRN: Monitor Status IP 500 4.0(11037) 2050891mS PRN: LAW=A PRI=0, BRI=4, ALOG=4, ADSL=0 VCOMP=32, MDM=0, WAN=0, MODU=0 LANM=0 CkSRC=0 VMAIL=0(VER=0 TYP=1) CALLS=0(TOT=1) 2129314mS PRN: Loading holdmusic.wav from ipad=255.255.255.255 2174319mS PRN: WAV Hold Music Load Failed 2457742mS SipDebugInfo: SIPTrunks: Make Target voip, line group id is 249 and ip of cba667f2 2457742mS SipDebugInfo: SIPTrunks: active channels 0 overall number 10 2457742mS SipDebugInfo: License, Valid 1, Available 255, Consumed 0 2457745mS SipDebugInfo: MZ extension is dialing 96677152@203.166.130.242 2457745mS 2457745mS 2457745mS 2457745mS 2457747mS 2457747mS 2457747mS 2457747mS SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo: MZ extension is dialing 96677152@203.166.130.242 ********************************************************* MZ: INVITE (method) SENT TO 203.166.103.242 5060 ********************************************************* ********************************************************* MZ: INVITE SENT TO 203.166.103.242 5060 ********************************************************* MZ: Entered Sip_sendToNetwork packet destination is 203.166.103.242

2457748mS SipDebugInfo: MZ SIPTrunk SendToTarget cba667f2, 5060 2457748mS SIP Trunk: 10:Tx INVITE sip:96677152@203.166.130.242 SIP/2.0 Via: SIP/2.0/UDP 211.27.21.53:5060;rport;branch=z9hG4bKc95a5f97a7d206629607ef8c25a77fc1 From: 357108 <sip:357108@mytel.net.au>;tag=4f9d0b6d969ac7b7 To: <sip:96677152@203.166.130.242> Call-ID: 7a85a3772f4969ae81c7c4579d12eb55@211.27.21.53 CSeq: 1755202939 INVITE Contact: 357108 <sip:357108@211.27.21.53:5060;transport=udp> Max-Forwards: 70 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE Content-Type: application/sdp Content-Length: 300 v=0 o=UserA 2191955339 564929546 IN IP4 211.27.21.53 s=Session SDP c=IN IP4 211.27.21.53 t=0 0 m=audio 49152 RTP/AVP 18 4 8 0 101 a=rtpmap:18 G729/8000 a=rtpmap:4 G723/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:0 PCMU/8000 a=fmtp:18 annexb = no a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 2457748mS SIP Tx: UDP 211.27.21.53:5060 -> 203.166.103.242:5060 INVITE sip:96677152@203.166.130.242 SIP/2.0 Via: SIP/2.0/UDP 211.27.21.53:5060;rport;branch=z9hG4bKc95a5f97a7d206629607ef8c25a77fc1 From: 357108 <sip:357108@mytel.net.au>;tag=4f9d0b6d969ac7b7 To: <sip:96677152@203.166.130.242> Call-ID: 7a85a3772f4969ae81c7c4579d12eb55@211.27.21.53 CSeq: 1755202939 INVITE Contact: 357108 <sip:357108@211.27.21.53:5060;transport=udp> Max-Forwards: 70 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE Content-Type: application/sdp Content-Length: 300 v=0 o=UserA 2191955339 564929546 IN IP4 211.27.21.53 s=Session SDP c=IN IP4 211.27.21.53 t=0 0 m=audio 49152 RTP/AVP 18 4 8 0 101 a=rtpmap:18 G729/8000 a=rtpmap:4 G723/8000

Page 90 of 133

2457748mS 2457749mS 2457749mS 2457749mS 2457749mS 2457870mS

a=rtpmap:8 PCMA/8000 a=rtpmap:0 PCMU/8000 a=fmtp:18 annexb = no a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 SipDebugInfo: initialising mTxnContext SipDebugInfo: ********************************************************* SipDebugInfo: State Transtion form Old State 0 to New state 1 SipDebugInfo: ********************************************************* SipDebugInfo: SIPDialog::UpdateSDPState has just transitioned to state 1 SIP Rx: UDP 203.166.103.242:5060 -> 211.27.21.53:5060

SIP/2.0 407 Proxy Authentication Required Via: SIP/2.0/UDP 211.27.21.53:5060;branch=z9hG4bKc95a5f97a7d206629607ef8c25a77fc1;received=211.27.21.53;rport=5060 From: 357108 <sip:357108@mytel.net.au>;tag=4f9d0b6d969ac7b7 To: <sip:96677152@203.166.130.242>;tag=as457ad6f5 Call-ID: 7a85a3772f4969ae81c7c4579d12eb55@211.27.21.53 CSeq: 1755202939 INVITE User-Agent: Asterisk PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Proxy-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="31e9766d" Content-Length: 0 2457870mS SIP Trunk: 10:Rx SIP/2.0 407 Proxy Authentication Required Via: SIP/2.0/UDP 211.27.21.53:5060;branch=z9hG4bKc95a5f97a7d206629607ef8c25a77fc1;received=211.27.21.53;rport=5060 From: 357108 <sip:357108@mytel.net.au>;tag=4f9d0b6d969ac7b7 To: <sip:96677152@203.166.130.242>;tag=as457ad6f5 Call-ID: 7a85a3772f4969ae81c7c4579d12eb55@211.27.21.53 CSeq: 1755202939 INVITE User-Agent: Asterisk PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Proxy-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="31e9766d" Content-Length: 0 2457870mS 2457872mS 2457872mS 2457872mS 2457872mS 2457873mS 2457873mS 2457873mS 2457873mS 2457873mS 2457874mS 2457874mS 2457874mS 2457874mS 2457874mS 2457874mS 2457874mS 2457874mS 2457875mS 2457875mS 2457876mS SipDebugInfo: MZ SIPDialog: ReceiveFromTarget SipDebugInfo: MZ SIPDialog TXN : Decoding of message Succeded 1 SipDebugInfo: SIP: ProcessInbound Message SipDebugInfo: MZ Find End Point 7a85a3772f4969ae81c7c4579d12eb55@211.27.21.53 SipDebugInfo: ProcessInboundSIPResponse SipDebugInfo: ExtractRouteFromRecord, entered SipDebugInfo: ExtractContactFromMessage: cannot get From Header 2012 SipDebugInfo: MZ SIP-EP: Decoding of 407 (challenge) RESPONSE SipDebugInfo: ProcessAuthenticationRequired: proxy is Digest SipDebugInfo: ProcessWWWAuthenticationRequired: Number of Challange Param is 3 SipDebugInfo: ProcessWWWAuthenticationRequired: realm is "asterisk" SipDebugInfo: ProcessWWWAuthenticationRequired: realm length 10 SipDebugInfo: ProcessWWWAuthenticationRequired: nonce is "31e9766d" SipDebugInfo: ProcessWWWAuthenticationRequired: nonce lentgh 10 SipDebugInfo: ********************************************************* SipDebugInfo: State Transtion form Old State 1 to New state 17 SipDebugInfo: ********************************************************* SipDebugInfo: ********************************************************* SipDebugInfo: MZ: ACK SENT TO 203.166.103.242 5060 SipDebugInfo: ********************************************************* SipDebugInfo: MZ: Entered Sip_sendToNetwork packet destination is 203.166.103.242

2457876mS SipDebugInfo: MZ SIPTrunk SendToTarget cba667f2, 5060 2457876mS SIP Trunk: 10:Tx ACK sip:96677152@203.166.130.242 SIP/2.0 Via: SIP/2.0/UDP 211.27.21.53:5060;rport;branch=z9hG4bKc95a5f97a7d206629607ef8c25a77fc1 From: 357108 <sip:357108@mytel.net.au>;tag=4f9d0b6d969ac7b7 To: <sip:96677152@203.166.130.242>;tag=as457ad6f5 Call-ID: 7a85a3772f4969ae81c7c4579d12eb55@211.27.21.53 CSeq: 1755202939 ACK Max-Forwards: 70 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE Content-Length: 0

Page 91 of 133

2457876mS SIP Tx: UDP 211.27.21.53:5060 -> 203.166.103.242:5060 ACK sip:96677152@203.166.130.242 SIP/2.0 Via: SIP/2.0/UDP 211.27.21.53:5060;rport;branch=z9hG4bKc95a5f97a7d206629607ef8c25a77fc1 From: 357108 <sip:357108@mytel.net.au>;tag=4f9d0b6d969ac7b7 To: <sip:96677152@203.166.130.242>;tag=as457ad6f5 Call-ID: 7a85a3772f4969ae81c7c4579d12eb55@211.27.21.53 CSeq: 1755202939 ACK Max-Forwards: 70 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE Content-Length: 0 2457877mS 2457877mS 2457877mS 2457877mS 2457877mS 2457878mS 2457878mS 2457879mS SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo: ********************************************************* State Transtion form Old State 17 to New state 9 ********************************************************* ********************************************************* MZ: INVITE SENT TO 203.166.103.242 5060 ********************************************************* building authorisation header .... MZ: Entered Sip_sendToNetwork packet destination is 203.166.103.242

2457879mS SipDebugInfo: MZ SIPTrunk SendToTarget cba667f2, 5060 2457880mS SIP Tx: UDP 211.27.21.53:5060 -> 203.166.103.242:5060 INVITE sip:96677152@203.166.130.242 SIP/2.0 Via: SIP/2.0/UDP 211.27.21.53:5060;rport;branch=z9hG4bK9d6e438a5d7f9dde0f32c82e9feb1421 From: 357108 <sip:357108@mytel.net.au>;tag=4f9d0b6d969ac7b7 To: <sip:96677152@203.166.130.242> Call-ID: 7a85a3772f4969ae81c7c4579d12eb55@211.27.21.53 CSeq: 1755202940 INVITE Contact: 357108 <sip:357108@211.27.21.53:5060;transport=udp> Max-Forwards: 70 Proxy-Authorization: Digest username="357108",realm="asterisk",nonce="31e9766d",response="d2df6503c607eba8407d53995ca6fa60",uri="sip:96677152@203. 166.130.242" Content-Type: application/sdp Content-Length: 300 v=0 o=UserA 2191955339 564929547 IN IP4 211.27.21.53 s=Session SDP c=IN IP4 211.27.21.53 t=0 0 m=audio 49152 RTP/AVP 18 4 8 0 101 a=rtpmap:18 G729/8000 a=rtpmap:4 G723/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:0 PCMU/8000 a=fmtp:18 annexb = no a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 SipDebugInfo: ********************************************************* SipDebugInfo: State Transtion form Old State 9 to New state 4 SipDebugInfo: ********************************************************* SipDebugInfo: SipTrunks: Cannot free Txn Key 2015 SIP Rx: UDP 203.166.103.242:5060 -> 211.27.21.53:5060

2457881mS 2457881mS 2457881mS 2457881mS 2458116mS

SIP/2.0 100 Trying Via: SIP/2.0/UDP 211.27.21.53:5060;branch=z9hG4bK9d6e438a5d7f9dde0f32c82e9feb1421;received=211.27.21.53;rport=5060 From: 357108 <sip:357108@mytel.net.au>;tag=4f9d0b6d969ac7b7 To: <sip:96677152@203.166.130.242> Call-ID: 7a85a3772f4969ae81c7c4579d12eb55@211.27.21.53 CSeq: 1755202940 INVITE User-Agent: Asterisk PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Contact: <sip:96677152@203.166.103.242> Content-Length: 0

Page 92 of 133

2458117mS SIP Trunk: 10:Rx SIP/2.0 100 Trying Via: SIP/2.0/UDP 211.27.21.53:5060;branch=z9hG4bK9d6e438a5d7f9dde0f32c82e9feb1421;received=211.27.21.53;rport=5060 From: 357108 <sip:357108@mytel.net.au>;tag=4f9d0b6d969ac7b7 To: <sip:96677152@203.166.130.242> Call-ID: 7a85a3772f4969ae81c7c4579d12eb55@211.27.21.53 CSeq: 1755202940 INVITE User-Agent: Asterisk PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Contact: <sip:96677152@203.166.103.242> Content-Length: 0 2458117mS 2458118mS 2458119mS 2458119mS 2458119mS 2458119mS 2458119mS 2458120mS 2458120mS 2458120mS 2458120mS 2458145mS SipDebugInfo: MZ SIPDialog: ReceiveFromTarget SipDebugInfo: MZ SIPDialog TXN : Decoding of message Succeded 1 SipDebugInfo: SIP: ProcessInbound Message SipDebugInfo: MZ Find End Point 7a85a3772f4969ae81c7c4579d12eb55@211.27.21.53 SipDebugInfo: ProcessInboundSIPResponse SipDebugInfo: MZ SIPDialog No Tag due to error SipDebugInfo: ExtractRouteFromRecord, entered SipDebugInfo: ********************************************************* SipDebugInfo: State Transtion form Old State 4 to New state 5 SipDebugInfo: ********************************************************* SipDebugInfo: SipTrunks: Cannot free Txn Key 2015 SIP Rx: UDP 203.166.103.242:5060 -> 211.27.21.53:5060

SIP/2.0 183 Session Progress Via: SIP/2.0/UDP 211.27.21.53:5060;branch=z9hG4bK9d6e438a5d7f9dde0f32c82e9feb1421;received=211.27.21.53;rport=5060 From: 357108 <sip:357108@mytel.net.au>;tag=4f9d0b6d969ac7b7 To: <sip:96677152@203.166.130.242>;tag=as1670caf8 Call-ID: 7a85a3772f4969ae81c7c4579d12eb55@211.27.21.53 CSeq: 1755202940 INVITE User-Agent: Asterisk PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Contact: <sip:96677152@203.166.103.242> Content-Type: application/sdp Content-Length: 293 v=0 o=root 25758 25758 IN IP4 203.166.103.242 s=session c=IN IP4 203.166.103.242 t=0 0 m=audio 10268 RTP/AVP 0 8 18 101 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=silenceSupp:off - - - 2458145mS SIP Trunk: 10:Rx SIP/2.0 183 Session Progress Via: SIP/2.0/UDP 211.27.21.53:5060;branch=z9hG4bK9d6e438a5d7f9dde0f32c82e9feb1421;received=211.27.21.53;rport=5060 From: 357108 <sip:357108@mytel.net.au>;tag=4f9d0b6d969ac7b7 To: <sip:96677152@203.166.130.242>;tag=as1670caf8 Call-ID: 7a85a3772f4969ae81c7c4579d12eb55@211.27.21.53 CSeq: 1755202940 INVITE User-Agent: Asterisk PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Contact: <sip:96677152@203.166.103.242> Content-Type: application/sdp Content-Length: 293 v=0 o=root 25758 25758 IN IP4 203.166.103.242 s=session c=IN IP4 203.166.103.242 t=0 0

Page 93 of 133

m=audio 10268 RTP/AVP 0 8 18 101 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=silenceSupp:off - - - 2458146mS SipDebugInfo: MZ SIPDialog: ReceiveFromTarget 2458148mS SipDebugInfo: MZ SIPDialog TXN : Decoding of message Succeded 1 2458148mS SipDebugInfo: SIP: ProcessInbound Message 2458149mS SipDebugInfo: MZ Find End Point 7a85a3772f4969ae81c7c4579d12eb55@211.27.21.53 2458149mS SipDebugInfo: ProcessInboundSIPResponse 2458149mS SipDebugInfo: ExtractRouteFromRecord, entered 2458149mS SipDebugInfo: ********************************************************* 2458149mS SipDebugInfo: State Transtion form Old State 5 to New state 41 2458150mS SipDebugInfo: ********************************************************* 2458153mS SipDebugInfo: SIPDialog::UpdateSDPState has just transitioned to state 7 2458153mS SipDebugInfo: SipTrunks: Cannot free Txn Key 2015 2458154mS PRN: SetRfc2833 (1): rx payload 101 tx payload 101 2458154mS PRN: SetRfc2833 (1): rx payload 101 tx payload 101 2458155mS PRN: SetRfc2833 (1): rx payload 101 tx payload 101 2459922mS SIP Rx: UDP 203.166.103.242:5060 -> 211.27.21.53:5060 SIP/2.0 180 Ringing Via: SIP/2.0/UDP 211.27.21.53:5060;branch=z9hG4bK9d6e438a5d7f9dde0f32c82e9feb1421;received=211.27.21.53;rport=5060 From: 357108 <sip:357108@mytel.net.au>;tag=4f9d0b6d969ac7b7 To: <sip:96677152@203.166.130.242>;tag=as1670caf8 Call-ID: 7a85a3772f4969ae81c7c4579d12eb55@211.27.21.53 CSeq: 1755202940 INVITE User-Agent: Asterisk PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Contact: <sip:96677152@203.166.103.242> Content-Length: 0 2459922mS SIP Trunk: 10:Rx SIP/2.0 180 Ringing Via: SIP/2.0/UDP 211.27.21.53:5060;branch=z9hG4bK9d6e438a5d7f9dde0f32c82e9feb1421;received=211.27.21.53;rport=5060 From: 357108 <sip:357108@mytel.net.au>;tag=4f9d0b6d969ac7b7 To: <sip:96677152@203.166.130.242>;tag=as1670caf8 Call-ID: 7a85a3772f4969ae81c7c4579d12eb55@211.27.21.53 CSeq: 1755202940 INVITE User-Agent: Asterisk PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Contact: <sip:96677152@203.166.103.242> Content-Length: 0 2459922mS 2459924mS 2459924mS 2459924mS 2459924mS 2459925mS 2459925mS 2461265mS SipDebugInfo: MZ SIPDialog: ReceiveFromTarget SipDebugInfo: MZ SIPDialog TXN : Decoding of message Succeded 1 SipDebugInfo: SIP: ProcessInbound Message SipDebugInfo: MZ Find End Point 7a85a3772f4969ae81c7c4579d12eb55@211.27.21.53 SipDebugInfo: ProcessInboundSIPResponse SipDebugInfo: ExtractRouteFromRecord, entered SipDebugInfo: SipTrunks: Cannot free Txn Key 2015 SIP Rx: UDP 203.166.103.242:5060 -> 211.27.21.53:5060

SIP/2.0 200 OK Via: SIP/2.0/UDP 211.27.21.53:5060;branch=z9hG4bK9d6e438a5d7f9dde0f32c82e9feb1421;received=211.27.21.53;rport=5060 From: 357108 <sip:357108@mytel.net.au>;tag=4f9d0b6d969ac7b7 To: <sip:96677152@203.166.130.242>;tag=as1670caf8 Call-ID: 7a85a3772f4969ae81c7c4579d12eb55@211.27.21.53 CSeq: 1755202940 INVITE User-Agent: Asterisk PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Contact: <sip:96677152@203.166.103.242> Content-Type: application/sdp Content-Length: 293

Page 94 of 133

v=0 o=root 25758 25759 IN IP4 203.166.103.242 s=session c=IN IP4 203.166.103.242 t=0 0 m=audio 10268 RTP/AVP 0 8 18 101 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=silenceSupp:off - - - 2461265mS SIP Trunk: 10:Rx SIP/2.0 200 OK Via: SIP/2.0/UDP 211.27.21.53:5060;branch=z9hG4bK9d6e438a5d7f9dde0f32c82e9feb1421;received=211.27.21.53;rport=5060 From: 357108 <sip:357108@mytel.net.au>;tag=4f9d0b6d969ac7b7 To: <sip:96677152@203.166.130.242>;tag=as1670caf8 Call-ID: 7a85a3772f4969ae81c7c4579d12eb55@211.27.21.53 CSeq: 1755202940 INVITE User-Agent: Asterisk PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Contact: <sip:96677152@203.166.103.242> Content-Type: application/sdp Content-Length: 293 v=0 o=root 25758 25759 IN IP4 203.166.103.242 s=session c=IN IP4 203.166.103.242 t=0 0 m=audio 10268 RTP/AVP 0 8 18 101 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=silenceSupp:off - - - 2461265mS SipDebugInfo: MZ SIPDialog: ReceiveFromTarget 2461268mS SipDebugInfo: MZ SIPDialog TXN : Decoding of message Succeded 1 2461268mS SipDebugInfo: SIP: ProcessInbound Message 2461268mS SipDebugInfo: MZ Find End Point 7a85a3772f4969ae81c7c4579d12eb55@211.27.21.53 2461268mS SipDebugInfo: ProcessInboundSIPResponse 2461269mS SipDebugInfo: ExtractRouteFromRecord, entered 2461269mS SipDebugInfo: SIPDialog::UpdateSDPState has just transitioned to state 4 2461269mS SipDebugInfo: ********************************************************* 2461269mS SipDebugInfo: MZ: ACK SENT TO 203.166.103.242 5060 2461270mS SipDebugInfo: MZ: Entered Sip_sendToNetwork packet destination is 203.166.103.242 2461271mS SipDebugInfo: MZ SIPTrunk SendToTarget cba667f2, 5060 2461271mS SIP Trunk: 10:Tx ACK sip:96677152@203.166.103.242 SIP/2.0 Via: SIP/2.0/UDP 211.27.21.53:5060;rport;branch=z9hG4bK9d6e438a5d7f9dde0f32c82e9feb1421 From: 357108 <sip:357108@mytel.net.au>;tag=4f9d0b6d969ac7b7 To: <sip:96677152@203.166.130.242>;tag=as1670caf8 Call-ID: 7a85a3772f4969ae81c7c4579d12eb55@211.27.21.53 CSeq: 1755202940 ACK Max-Forwards: 70 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE Content-Length: 0 2461271mS SIP Tx: UDP 211.27.21.53:5060 -> 203.166.103.242:5060 ACK sip:96677152@203.166.103.242 SIP/2.0 Via: SIP/2.0/UDP 211.27.21.53:5060;rport;branch=z9hG4bK9d6e438a5d7f9dde0f32c82e9feb1421 From: 357108 <sip:357108@mytel.net.au>;tag=4f9d0b6d969ac7b7 To: <sip:96677152@203.166.130.242>;tag=as1670caf8 Call-ID: 7a85a3772f4969ae81c7c4579d12eb55@211.27.21.53 CSeq: 1755202940 ACK Max-Forwards: 70

Page 95 of 133

Allow: INVITE, ACK, CANCEL, OPTIONS, BYE Content-Length: 0 2461272mS SipDebugInfo: SIPDialog::SendCMMessageFromSDP: 7 attribute fields 2461274mS SipDebugInfo: ******************CMMessage received 11 2461274mS SipDebugInfo: SDP Outcome is : 1 2461274mS SipDebugInfo: ********************************************************* 2461274mS SipDebugInfo: State Transtion form Old State 41 to New state 16 2461275mS SipDebugInfo: ********************************************************* 2461275mS SipDebugInfo: SIPDialog::UpdateSDPState has just transitioned to state 7 2461275mS SipDebugInfo: ********************************************************* 2461275mS SipDebugInfo: State Transtion form Old State 16 to New state 16 2461275mS SipDebugInfo: ********************************************************* 2461275mS SipDebugInfo: SipTrunks: Cannot free Txn Key 2015 2465272mS SIP Rx: UDP 203.166.103.242:5060 -> 211.27.21.53:5060 BYE sip:357108@211.27.21.53:5060 SIP/2.0 Via: SIP/2.0/UDP 203.166.103.242:5060;branch=z9hG4bK754b2313;rport From: <sip:96677152@203.166.130.242>;tag=as1670caf8 To: 357108 <sip:357108@mytel.net.au>;tag=4f9d0b6d969ac7b7 Contact: <sip:96677152@203.166.103.242> Call-ID: 7a85a3772f4969ae81c7c4579d12eb55@211.27.21.53 CSeq: 102 BYE User-Agent: Asterisk PBX Max-Forwards: 70 Content-Length: 0 2465272mS SIP Trunk: 10:Rx BYE sip:357108@211.27.21.53:5060 SIP/2.0 Via: SIP/2.0/UDP 203.166.103.242:5060;branch=z9hG4bK754b2313;rport From: <sip:96677152@203.166.130.242>;tag=as1670caf8 To: 357108 <sip:357108@mytel.net.au>;tag=4f9d0b6d969ac7b7 Contact: <sip:96677152@203.166.103.242> Call-ID: 7a85a3772f4969ae81c7c4579d12eb55@211.27.21.53 CSeq: 102 BYE User-Agent: Asterisk PBX Max-Forwards: 70 Content-Length: 0 2465272mS 2465274mS 2465274mS 2465274mS 2465274mS 2465274mS 2465275mS 2465275mS 2465275mS SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo: MZ SIPDialog: ReceiveFromTarget MZ SIPDialog TXN : Decoding of message Succeded 1 SIP: ProcessInbound Message MZ Find End Point 7a85a3772f4969ae81c7c4579d12eb55@211.27.21.53 Process SIP request BYE Cannot Clone, message does not exist !!!!!!! SendSIPResponse SendSIPResponse, Number of Tag Count, 1 MZ: Entered Sip_sendToNetwork packet destination is 203.166.103.242

2465275mS SipDebugInfo: MZ SIPTrunk SendToTarget cba667f2, 5060 2465276mS SIP Trunk: 10:Tx SIP/2.0 200 Ok Via: SIP/2.0/UDP 203.166.103.242:5060;branch=z9hG4bK754b2313;rport From: <sip:96677152@203.166.130.242>;tag=as1670caf8 To: 357108 <sip:357108@mytel.net.au>;tag=4f9d0b6d969ac7b7 Call-ID: 7a85a3772f4969ae81c7c4579d12eb55@211.27.21.53 CSeq: 102 BYE Content-Length: 0 2465276mS SIP Tx: UDP 211.27.21.53:5060 -> 203.166.103.242:5060 SIP/2.0 200 Ok Via: SIP/2.0/UDP 203.166.103.242:5060;branch=z9hG4bK754b2313;rport From: <sip:96677152@203.166.130.242>;tag=as1670caf8 To: 357108 <sip:357108@mytel.net.au>;tag=4f9d0b6d969ac7b7 Call-ID: 7a85a3772f4969ae81c7c4579d12eb55@211.27.21.53 CSeq: 102 BYE Content-Length: 0 2465276mS SipDebugInfo: *********************************************************

Page 96 of 133

2465276mS 2465277mS 2465279mS 2465279mS 2465279mS 2465280mS 2465281mS

SipDebugInfo: State Transtion form Old State 16 to New state 22 SipDebugInfo: ********************************************************* SipDebugInfo: Call Lost is entered casue is 16, state is 23 SipDebugInfo: SIPDialog destructor ... SipDebugInfo: SIPDialog - Free SDPBody.... SipDebugInfo: Call Lost is about to delete endpoint SipDebugInfo: SipTrunks: Freed Txn Key 2016

Page 97 of 133

Soul Configuration The testing was conducted on 4.0 Pre Release Notes: Soul require the number to be presented to them in International format Eg: +61296677152 or 611800816818 Soul SIP accounts require that you give them the Public IP address the SIP INVITE will come from, registration is not required because of this, this was the case with the account we were given for testing. Details given to us by Soul SIP Server address 125.254.25.2 Note: they have configured the account to only accept sessions from our public IP Address being 203.27.21.53 In-dial Provided 0290074083 See below Screen Shot of the SIP Line 11

Page 98 of 133

We gave the Line Incoming and Outgoing Group 250 All Local URI, Contact and Display names were set to Use User Data See below ARS configuration including SIP Short code for 9 numbers; note the required international formatting which is required by Soul

Page 99 of 133

INCOMING CONFIGURATION The SIP Name on Extn210 was 61290074083 which is the in-dial we were given

See below incoming call route for Line Group 251, When 0290074083 was dialled the call would route in an ring on Extn210

Page 100 of 133

See below Sys-Monitor trace of Extension 210 to 96677152 via SIP Line 250 as per ARS above
4166434mS SipDebugInfo: Timer 4 callback 4166917mS SipDebugInfo: SIPTrunks: Make Target voip, line group id is 250 and ip of cba667f2 4166917mS SipDebugInfo: SIPTrunks cannot find a suitable SIP URI to dial out 4166917mS SipDebugInfo: SIPTrunks: Make Target voip, line group id is 250 and ip of 7dfe1902 4166917mS SipDebugInfo: SIPTrunks: active channels 0 overall number 10 4166918mS SipDebugInfo: License, Valid 1, Available 255, Consumed 0 4166920mS SipDebugInfo: MZ extension is dialing 61296677152@125.254.25.2 4166920mS 4166920mS 4166920mS 4166920mS 4166922mS 4166922mS 4166922mS 4166923mS SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo: MZ extension is dialing 61296677152@125.254.25.2 ********************************************************* MZ: INVITE (method) SENT TO 125.254.25.2 5060 ********************************************************* ********************************************************* MZ: INVITE SENT TO 125.254.25.2 5060 ********************************************************* MZ: Entered Sip_sendToNetwork packet destination is 125.254.25.2

4166923mS SipDebugInfo: MZ SIPTrunk SendToTarget 7dfe1902, 5060 4166923mS SIP Trunk: 11:Tx INVITE sip:61296677152@125.254.25.2 SIP/2.0 Via: SIP/2.0/UDP 211.27.21.53:5060;rport;branch=z9hG4bKadc5c5ab2bb3541eca3d63acc7052b6a From: Extn210 <sip:Extn210@soulaustralia.com.au>;tag=160a19c954b9aeb9 To: <sip:61296677152@125.254.25.2> Call-ID: 96a430d6919ef491e61bbad8fa515d6d@211.27.21.53 CSeq: 1122424747 INVITE Contact: Extn210 <sip:Extn210@211.27.21.53:5060;transport=udp> Max-Forwards: 70 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE Content-Type: application/sdp Content-Length: 301 v=0 o=UserA 3196822098 1040470160 IN IP4 211.27.21.53 s=Session SDP c=IN IP4 211.27.21.53 t=0 0 m=audio 49152 RTP/AVP 18 4 8 0 101 a=rtpmap:18 G729/8000 a=rtpmap:4 G723/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:0 PCMU/8000 a=fmtp:18 annexb = no a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 4166923mS SIP Tx: UDP 211.27.21.53:5060 -> 125.254.25.2:5060 INVITE sip:61296677152@125.254.25.2 SIP/2.0 Via: SIP/2.0/UDP 211.27.21.53:5060;rport;branch=z9hG4bKadc5c5ab2bb3541eca3d63acc7052b6a From: Extn210 <sip:Extn210@soulaustralia.com.au>;tag=160a19c954b9aeb9 To: <sip:61296677152@125.254.25.2> Call-ID: 96a430d6919ef491e61bbad8fa515d6d@211.27.21.53 CSeq: 1122424747 INVITE Contact: Extn210 <sip:Extn210@211.27.21.53:5060;transport=udp> Max-Forwards: 70 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE Content-Type: application/sdp Content-Length: 301 v=0 o=UserA 3196822098 1040470160 IN IP4 211.27.21.53 s=Session SDP c=IN IP4 211.27.21.53 t=0 0 m=audio 49152 RTP/AVP 18 4 8 0 101 a=rtpmap:18 G729/8000 a=rtpmap:4 G723/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:0 PCMU/8000

Page 101 of 133

4166924mS 4166924mS 4166924mS 4166924mS 4166925mS 4167064mS

a=fmtp:18 annexb = no a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 SipDebugInfo: initialising mTxnContext SipDebugInfo: ********************************************************* SipDebugInfo: State Transtion form Old State 0 to New state 1 SipDebugInfo: ********************************************************* SipDebugInfo: SIPDialog::UpdateSDPState has just transitioned to state 1 SIP Rx: UDP 125.254.25.2:5060 -> 211.27.21.53:5060 SIP/2.0 100 Trying Via: SIP/2.0/UDP 211.27.21.53:5060;rport;branch=z9hG4bKadc5c5ab2bb3541eca3d63acc7052b6a From: Extn210 <sip:Extn210@soulaustralia.com.au>;tag=160a19c954b9aeb9 To: <sip:61296677152@125.254.25.2> Call-ID: 96a430d6919ef491e61bbad8fa515d6d@211.27.21.53 CSeq: 1122424747 INVITE Content-Length: 0

4167064mS SIP Trunk: 11:Rx SIP/2.0 100 Trying Via: SIP/2.0/UDP 211.27.21.53:5060;rport;branch=z9hG4bKadc5c5ab2bb3541eca3d63acc7052b6a From: Extn210 <sip:Extn210@soulaustralia.com.au>;tag=160a19c954b9aeb9 To: <sip:61296677152@125.254.25.2> Call-ID: 96a430d6919ef491e61bbad8fa515d6d@211.27.21.53 CSeq: 1122424747 INVITE Content-Length: 0 4167065mS 4167066mS 4167066mS 4167066mS 4167066mS 4167067mS 4167067mS 4167068mS 4167068mS 4167069mS 4167069mS 4168775mS SipDebugInfo: MZ SIPDialog: ReceiveFromTarget SipDebugInfo: MZ SIPDialog TXN : Decoding of message Succeded 1 SipDebugInfo: SIP: ProcessInbound Message SipDebugInfo: MZ Find End Point 96a430d6919ef491e61bbad8fa515d6d@211.27.21.53 SipDebugInfo: ProcessInboundSIPResponse SipDebugInfo: MZ SIPDialog No Tag due to error SipDebugInfo: ExtractRouteFromRecord, entered SipDebugInfo: ********************************************************* SipDebugInfo: State Transtion form Old State 1 to New state 5 SipDebugInfo: ********************************************************* SipDebugInfo: SipTrunks: Cannot free Txn Key 2015 SIP Rx: UDP 125.254.25.2:5060 -> 211.27.21.53:5060 SIP/2.0 180 Ringing To: <sip:61296677152@125.254.25.2>;tag=3374884284-564851 From: Extn210 <sip:Extn210@soulaustralia.com.au>;tag=160a19c954b9aeb9 Contact: sip:61296677152@125.254.25.2:5060 Call-ID: 96a430d6919ef491e61bbad8fa515d6d@211.27.21.53 CSeq: 1122424747 INVITE Content-Type: application/sdp Via: SIP/2.0/UDP 211.27.21.53:5060;rport;branch=z9hG4bKadc5c5ab2bb3541eca3d63acc7052b6a Content-Length: 227 v=0 o=MSX02-KENT-SYD 1793550 0 IN IP4 125.254.25.2 s=sip call c=IN IP4 125.254.25.65 t=0 0 m=audio 22252 RTP/AVP 18 101 100 a=fmtp:100 192-194 a=rtpmap:100 X-NSE/8000 a=fmtp:101 0-15 a=rtpmap:101 telephone-event/8000 4168775mS SIP Trunk: 11:Rx SIP/2.0 180 Ringing To: <sip:61296677152@125.254.25.2>;tag=3374884284-564851 From: Extn210 <sip:Extn210@soulaustralia.com.au>;tag=160a19c954b9aeb9 Contact: sip:61296677152@125.254.25.2:5060 Call-ID: 96a430d6919ef491e61bbad8fa515d6d@211.27.21.53 CSeq: 1122424747 INVITE Content-Type: application/sdp Via: SIP/2.0/UDP 211.27.21.53:5060;rport;branch=z9hG4bKadc5c5ab2bb3541eca3d63acc7052b6a Content-Length: 227

Page 102 of 133

v=0 o=MSX02-KENT-SYD 1793550 0 IN IP4 125.254.25.2 s=sip call c=IN IP4 125.254.25.65 t=0 0 m=audio 22252 RTP/AVP 18 101 100 a=fmtp:100 192-194 a=rtpmap:100 X-NSE/8000 a=fmtp:101 0-15 a=rtpmap:101 telephone-event/8000 ********** Warning: Missed 1 packet(s) ********** 4168778mS 4168778mS 4168778mS 4168778mS 4168779mS 4168779mS 4168779mS 4168779mS 4168779mS 4168779mS 4168782mS 4168782mS 4168783mS 4168783mS 4168783mS 4170832mS SipDebugInfo: MZ SIPDialog TXN : Decoding of message Succeded 1 SipDebugInfo: SIP: ProcessInbound Message SipDebugInfo: MZ Find End Point 96a430d6919ef491e61bbad8fa515d6d@211.27.21.53 SipDebugInfo: ProcessInboundSIPResponse SipDebugInfo: ExtractRouteFromRecord, entered SipDebugInfo: ********************************************************* SipDebugInfo: State Transtion form Old State 5 to New state 41 SipDebugInfo: ********************************************************* SipDebugInfo: SIPDialog::UpdateSDPState has just transitioned to state 4 SipDebugInfo: SIPDialog::SendCMMessageFromSDP: 4 attribute fields SipDebugInfo: SIPDialog::UpdateSDPState has just transitioned to state 7 SipDebugInfo: SipTrunks: Cannot free Txn Key 2015 PRN: SetRfc2833 (1): rx payload 101 tx payload 101 PRN: SetRfc2833 (1): rx payload 101 tx payload 101 PRN: SetRfc2833 (1): rx payload 101 tx payload 101 SIP Rx: UDP 125.254.25.2:5060 -> 211.27.21.53:5060 SIP/2.0 200 OK To: <sip:61296677152@125.254.25.2>;tag=3374884284-564851 From: Extn210 <sip:Extn210@soulaustralia.com.au>;tag=160a19c954b9aeb9 Contact: sip:61296677152@125.254.25.2:5060 Call-ID: 96a430d6919ef491e61bbad8fa515d6d@211.27.21.53 CSeq: 1122424747 INVITE Content-Type: application/sdp Via: SIP/2.0/UDP 211.27.21.53:5060;rport;branch=z9hG4bKadc5c5ab2bb3541eca3d63acc7052b6a Content-Length: 227 v=0 o=MSX02-KENT-SYD 1793550 0 IN IP4 125.254.25.2 s=sip call c=IN IP4 125.254.25.65 t=0 0 m=audio 22252 RTP/AVP 18 101 100 a=fmtp:100 192-194 a=rtpmap:100 X-NSE/8000 a=fmtp:101 0-15 a=rtpmap:101 telephone-event/8000 4170832mS SIP Trunk: 11:Rx SIP/2.0 200 OK To: <sip:61296677152@125.254.25.2>;tag=3374884284-564851 From: Extn210 <sip:Extn210@soulaustralia.com.au>;tag=160a19c954b9aeb9 Contact: sip:61296677152@125.254.25.2:5060 Call-ID: 96a430d6919ef491e61bbad8fa515d6d@211.27.21.53 CSeq: 1122424747 INVITE Content-Type: application/sdp Via: SIP/2.0/UDP 211.27.21.53:5060;rport;branch=z9hG4bKadc5c5ab2bb3541eca3d63acc7052b6a Content-Length: 227 v=0 o=MSX02-KENT-SYD 1793550 0 IN IP4 125.254.25.2 s=sip call c=IN IP4 125.254.25.65 t=0 0 m=audio 22252 RTP/AVP 18 101 100 a=fmtp:100 192-194 a=rtpmap:100 X-NSE/8000 a=fmtp:101 0-15 a=rtpmap:101 telephone-event/8000

Page 103 of 133

4170833mS 4170835mS 4170835mS 4170835mS 4170835mS 4170836mS 4170836mS 4170836mS 4170836mS 4170836mS 4170837mS

SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo:

MZ SIPDialog: ReceiveFromTarget MZ SIPDialog TXN : Decoding of message Succeded 1 SIP: ProcessInbound Message MZ Find End Point 96a430d6919ef491e61bbad8fa515d6d@211.27.21.53 ProcessInboundSIPResponse ExtractRouteFromRecord, entered SIPDialog::UpdateSDPState has just transitioned to state 4 ********************************************************* MZ: ACK SENT TO 125.254.25.2 5060 ********************************************************* MZ: Entered Sip_sendToNetwork packet destination is 125.254.25.2

4170837mS SipDebugInfo: MZ SIPTrunk SendToTarget 7dfe1902, 5060 4170838mS SIP Trunk: 11:Tx ACK sip:61296677152@125.254.25.2:5060 SIP/2.0 Via: SIP/2.0/UDP 211.27.21.53:5060;rport;branch=z9hG4bKadc5c5ab2bb3541eca3d63acc7052b6a From: Extn210 <sip:Extn210@soulaustralia.com.au>;tag=160a19c954b9aeb9 To: <sip:61296677152@125.254.25.2>;tag=3374884284-564851 Call-ID: 96a430d6919ef491e61bbad8fa515d6d@211.27.21.53 CSeq: 1122424747 ACK Max-Forwards: 70 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE Content-Length: 0 4170838mS SIP Tx: UDP 211.27.21.53:5060 -> 125.254.25.2:5060 ACK sip:61296677152@125.254.25.2:5060 SIP/2.0 Via: SIP/2.0/UDP 211.27.21.53:5060;rport;branch=z9hG4bKadc5c5ab2bb3541eca3d63acc7052b6a From: Extn210 <sip:Extn210@soulaustralia.com.au>;tag=160a19c954b9aeb9 To: <sip:61296677152@125.254.25.2>;tag=3374884284-564851 Call-ID: 96a430d6919ef491e61bbad8fa515d6d@211.27.21.53 CSeq: 1122424747 ACK Max-Forwards: 70 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE Content-Length: 0 4170838mS SipDebugInfo: SIPDialog::SendCMMessageFromSDP: 4 attribute fields 4170841mS SipDebugInfo: ******************CMMessage received 11 4170841mS SipDebugInfo: SDP Outcome is : 1 4170841mS SipDebugInfo: ********************************************************* 4170841mS SipDebugInfo: State Transtion form Old State 41 to New state 16 4170841mS SipDebugInfo: ********************************************************* 4170841mS SipDebugInfo: SIPDialog::UpdateSDPState has just transitioned to state 7 4170841mS SipDebugInfo: ********************************************************* 4170842mS SipDebugInfo: State Transtion form Old State 16 to New state 16 4170842mS SipDebugInfo: ********************************************************* 4170842mS SipDebugInfo: SipTrunks: Cannot free Txn Key 2015 4174046mS SIP Rx: UDP 125.254.25.2:5060 -> 211.27.21.53:5060 BYE sip:Extn210@211.27.21.53:5060;transport=udp SIP/2.0 Max-Forwards: 69 To: Extn210 <sip:Extn210@soulaustralia.com.au>;tag=160a19c954b9aeb9 From: <sip:61296677152@125.254.25.2>;tag=3374884284-564851 Contact: sip:61296677152@125.254.25.2:5060 Call-ID: 96a430d6919ef491e61bbad8fa515d6d@211.27.21.53 CSeq: 2 BYE Via: SIP/2.0/UDP 125.254.25.2:5060;branch=z9hG4bK8db10656cc434efdf178f007de55e91b Content-Length: 0 4174046mS SIP Trunk: 11:Rx BYE sip:Extn210@211.27.21.53:5060;transport=udp SIP/2.0 Max-Forwards: 69 To: Extn210 <sip:Extn210@soulaustralia.com.au>;tag=160a19c954b9aeb9 From: <sip:61296677152@125.254.25.2>;tag=3374884284-564851 Contact: sip:61296677152@125.254.25.2:5060 Call-ID: 96a430d6919ef491e61bbad8fa515d6d@211.27.21.53 CSeq: 2 BYE Via: SIP/2.0/UDP 125.254.25.2:5060;branch=z9hG4bK8db10656cc434efdf178f007de55e91b Content-Length: 0

Page 104 of 133

4174046mS 4174048mS 4174048mS 4174048mS 4174049mS 4174049mS 4174049mS 4174049mS 4174049mS

SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo:

MZ SIPDialog: ReceiveFromTarget MZ SIPDialog TXN : Decoding of message Succeded 1 SIP: ProcessInbound Message MZ Find End Point 96a430d6919ef491e61bbad8fa515d6d@211.27.21.53 Process SIP request BYE Cannot Clone, message does not exist !!!!!!! SendSIPResponse SendSIPResponse, Number of Tag Count, 1 MZ: Entered Sip_sendToNetwork packet destination is 125.254.25.2

4174050mS SipDebugInfo: MZ SIPTrunk SendToTarget 7dfe1902, 5060 4174050mS SIP Trunk: 11:Tx SIP/2.0 200 Ok Via: SIP/2.0/UDP 125.254.25.2:5060;branch=z9hG4bK8db10656cc434efdf178f007de55e91b From: <sip:61296677152@125.254.25.2>;tag=3374884284-564851 To: Extn210 <sip:Extn210@soulaustralia.com.au>;tag=160a19c954b9aeb9 Call-ID: 96a430d6919ef491e61bbad8fa515d6d@211.27.21.53 CSeq: 2 BYE Content-Length: 0 4174050mS SIP Tx: UDP 211.27.21.53:5060 -> 125.254.25.2:5060 SIP/2.0 200 Ok Via: SIP/2.0/UDP 125.254.25.2:5060;branch=z9hG4bK8db10656cc434efdf178f007de55e91b From: <sip:61296677152@125.254.25.2>;tag=3374884284-564851 To: Extn210 <sip:Extn210@soulaustralia.com.au>;tag=160a19c954b9aeb9 Call-ID: 96a430d6919ef491e61bbad8fa515d6d@211.27.21.53 CSeq: 2 BYE Content-Length: 0 4174051mS 4174051mS 4174051mS 4174053mS 4174053mS 4174053mS 4174054mS 4174055mS SipDebugInfo: ********************************************************* SipDebugInfo: State Transtion form Old State 16 to New state 22 SipDebugInfo: ********************************************************* SipDebugInfo: Call Lost is entered casue is 16, state is 23 SipDebugInfo: SIPDialog destructor ... SipDebugInfo: SIPDialog - Free SDPBody.... SipDebugInfo: Call Lost is about to delete endpoint SipDebugInfo: SipTrunks: Freed Txn Key 2016

Page 105 of 133

ISPhone Configuration The testing was conducted on 4.0 Pre Release Notes: ISPhone require the number to be presented to them in International format Eg: +61296677152 or 611800816818 ISPhone SIP account can be accessed from any public accessible device Providing authentication details are provided in the call set-up, and the IPO is registered against the SIP Proxy. Details we were given from the carrier Username and also incoming number: 61280022329 Password: XXXXXX (Hidden for Security Reasons) Sip server: sip2.isphone.com.au or 203.160.8.74 See blow reflection of IP Office Settings on Line 12

Page 106 of 133

We gave the Line Incoming and Outgoing Group 251 All Local URI, Contact and Display names were set to Use Authentication Name See below ARS configuration including SIP Short code for 9 numbers

Page 107 of 133

INCOMING CONFIGURATION

See below Sys-Monitor trace of Extension 210 to 96677152 via SIP Line 251 as per ARS above
5408843mS 5408844mS 5408844mS 5408844mS 5408844mS 5408844mS 5408844mS 5408847mS 5408847mS 5408847mS 5408847mS 5408847mS 5408849mS 5408849mS 5408849mS 5408850mS SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo: SIPTrunks: Make Target voip, line group id is 251 and ip of cba667f2 SIPTrunks cannot find a suitable SIP URI to dial out SIPTrunks: Make Target voip, line group id is 251 and ip of 7dfe1902 SIPTrunks cannot find a suitable SIP URI to dial out SIPTrunks: Make Target voip, line group id is 251 and ip of cba0084a SIPTrunks: active channels 0 overall number 10 License, Valid 1, Available 255, Consumed 0 MZ extension is dialing 61296677152@203.160.8.74 MZ extension is dialing 61296677152@203.160.8.74 ********************************************************* MZ: INVITE (method) SENT TO 203.160.8.74 5060 ********************************************************* ********************************************************* MZ: INVITE SENT TO 203.160.8.74 5060 ********************************************************* MZ: Entered Sip_sendToNetwork packet destination is 203.160.8.74

5408850mS SipDebugInfo: MZ SIPTrunk SendToTarget cba0084a, 5060 5408850mS SIP Trunk: 12:Tx INVITE sip:61296677152@203.160.8.74 SIP/2.0 Via: SIP/2.0/UDP 211.27.21.53:5060;rport;branch=z9hG4bK9272f7391fe31ef5ee55daf1de80eb75 From: 61280022329 <sip:61280022329@isphone.com.au>;tag=af53c7f79391b701 To: <sip:61296677152@203.160.8.74> Call-ID: 7183d5641f92f6934532a394197975ad@211.27.21.53 CSeq: 1654008671 INVITE Contact: 61280022329 <sip:61280022329@211.27.21.53:5060;transport=udp> Max-Forwards: 70 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE Content-Type: application/sdp Content-Length: 300 v=0 o=UserA 105622857 1976233741 IN IP4 211.27.21.53 s=Session SDP c=IN IP4 211.27.21.53 t=0 0 m=audio 49152 RTP/AVP 18 4 8 0 101 a=rtpmap:18 G729/8000 a=rtpmap:4 G723/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:0 PCMU/8000 a=fmtp:18 annexb = no a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 5408850mS SIP Tx: UDP 211.27.21.53:5060 -> 203.160.8.74:5060

Page 108 of 133

INVITE sip:61296677152@203.160.8.74 SIP/2.0 Via: SIP/2.0/UDP 211.27.21.53:5060;rport;branch=z9hG4bK9272f7391fe31ef5ee55daf1de80eb75 From: 61280022329 <sip:61280022329@isphone.com.au>;tag=af53c7f79391b701 To: <sip:61296677152@203.160.8.74> Call-ID: 7183d5641f92f6934532a394197975ad@211.27.21.53 CSeq: 1654008671 INVITE Contact: 61280022329 <sip:61280022329@211.27.21.53:5060;transport=udp> Max-Forwards: 70 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE Content-Type: application/sdp Content-Length: 300 v=0 o=UserA 105622857 1976233741 IN IP4 211.27.21.53 s=Session SDP c=IN IP4 211.27.21.53 t=0 0 m=audio 49152 RTP/AVP 18 4 8 0 101 a=rtpmap:18 G729/8000 a=rtpmap:4 G723/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:0 PCMU/8000 a=fmtp:18 annexb = no a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 SipDebugInfo: initialising mTxnContext SipDebugInfo: ********************************************************* SipDebugInfo: State Transtion form Old State 0 to New state 1 SipDebugInfo: ********************************************************* SipDebugInfo: SIPDialog::UpdateSDPState has just transitioned to state 1 SIP Rx: UDP 203.160.8.74:5060 -> 211.27.21.53:5060 SIP/2.0 100 trying -- your call is important to us Via: SIP/2.0/UDP 211.27.21.53:5060;rport=5060;branch=z9hG4bK9272f7391fe31ef5ee55daf1de80eb75 From: 61280022329 <sip:61280022329@isphone.com.au>;tag=af53c7f79391b701 To: <sip:61296677152@203.160.8.74> Call-ID: 7183d5641f92f6934532a394197975ad@211.27.21.53 CSeq: 1654008671 INVITE Server: Sip EXpress router (0.9.6 (i386/freebsd)) Content-Length: 0 5408973mS SIP Trunk: 12:Rx SIP/2.0 100 trying -- your call is important to us Via: SIP/2.0/UDP 211.27.21.53:5060;rport=5060;branch=z9hG4bK9272f7391fe31ef5ee55daf1de80eb75 From: 61280022329 <sip:61280022329@isphone.com.au>;tag=af53c7f79391b701 To: <sip:61296677152@203.160.8.74> Call-ID: 7183d5641f92f6934532a394197975ad@211.27.21.53 CSeq: 1654008671 INVITE Server: Sip EXpress router (0.9.6 (i386/freebsd)) Content-Length: 0 5408973mS 5408974mS 5408974mS 5408975mS 5408975mS 5408975mS 5408975mS 5408977mS 5408977mS 5408977mS 5408977mS 5408983mS SipDebugInfo: MZ SIPDialog: ReceiveFromTarget SipDebugInfo: MZ SIPDialog TXN : Decoding of message Succeded 1 SipDebugInfo: SIP: ProcessInbound Message SipDebugInfo: MZ Find End Point 7183d5641f92f6934532a394197975ad@211.27.21.53 SipDebugInfo: ProcessInboundSIPResponse SipDebugInfo: MZ SIPDialog No Tag due to error SipDebugInfo: ExtractRouteFromRecord, entered SipDebugInfo: ********************************************************* SipDebugInfo: State Transtion form Old State 1 to New state 5 SipDebugInfo: ********************************************************* SipDebugInfo: SipTrunks: Cannot free Txn Key 2015 SIP Rx: UDP 203.160.8.74:5060 -> 211.27.21.53:5060 SIP/2.0 401 Unauthorized Via: SIP/2.0/UDP 211.27.21.53:5060;rport=5060;branch=z9hG4bK9272f7391fe31ef5ee55daf1de80eb75 Record-Route: <sip:203.160.8.74;ftag=af53c7f79391b701;lr> From: 61280022329 <sip:61280022329@isphone.com.au>;tag=af53c7f79391b701 To: <sip:61296677152@203.160.8.74> Call-ID: 7183d5641f92f6934532a394197975ad@211.27.21.53

5408851mS 5408851mS 5408851mS 5408851mS 5408852mS 5408972mS

Page 109 of 133

CSeq: 1654008671 INVITE Server: Sippy WWW-Authenticate: Digest realm="203.160.8.74",nonce="c42dafb95f7971fd1db192d2fe141fe6457f66e9" 5408983mS SIP Trunk: 12:Rx SIP/2.0 401 Unauthorized Via: SIP/2.0/UDP 211.27.21.53:5060;rport=5060;branch=z9hG4bK9272f7391fe31ef5ee55daf1de80eb75 Record-Route: <sip:203.160.8.74;ftag=af53c7f79391b701;lr> From: 61280022329 <sip:61280022329@isphone.com.au>;tag=af53c7f79391b701 To: <sip:61296677152@203.160.8.74> Call-ID: 7183d5641f92f6934532a394197975ad@211.27.21.53 CSeq: 1654008671 INVITE Server: Sippy WWW-Authenticate: Digest realm="203.160.8.74",nonce="c42dafb95f7971fd1db192d2fe141fe6457f66e9" 5408984mS 5408985mS 5408985mS 5408985mS 5408986mS 5408986mS 5408986mS 5408986mS 5408987mS 5408987mS 5408987mS 5408987mS 5408987mS 5408987mS 5408987mS 5408988mS 5408988mS 5408988mS 5408988mS 5408988mS 5408988mS 5408990mS SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo: MZ SIPDialog: ReceiveFromTarget MZ SIPDialog TXN : Decoding of message Succeded 1 SIP: ProcessInbound Message MZ Find End Point 7183d5641f92f6934532a394197975ad@211.27.21.53 ProcessInboundSIPResponse MZ SIPDialog No Tag due to error ExtractRouteFromRecord, entered LR is On and route is Record-Route: <sip:203.160.8.74;ftag=af53c7f79391b701;lr>

SipDebugInfo: ExtractContactFromMessage: cannot get From Header 2012 SipDebugInfo: ProcessAuthenticationRequired: www is Digest SipDebugInfo: ProcessWWWAuthenticationRequired: Number of Challange Param is 2 SipDebugInfo: ProcessWWWAuthenticationRequired: realm is "203.160.8.74" SipDebugInfo: ProcessWWWAuthenticationRequired: realm length 14 SipDebugInfo: ProcessWWWAuthenticationRequired: nonce is "c42dafb95f7971fd1db192d2fe141fe6457f66e9" SipDebugInfo: ProcessWWWAuthenticationRequired: nonce lentgh 42 SipDebugInfo: ********************************************************* SipDebugInfo: State Transtion form Old State 5 to New state 17 SipDebugInfo: ********************************************************* SipDebugInfo: ********************************************************* SipDebugInfo: MZ: ACK SENT TO 203.160.8.74 5060 SipDebugInfo: ********************************************************* SipDebugInfo: MZ: Entered Sip_sendToNetwork packet destination is 203.160.8.74

5408990mS SipDebugInfo: MZ SIPTrunk SendToTarget cba0084a, 5060 5408990mS SIP Trunk: 12:Tx ACK sip:61296677152@203.160.8.74 SIP/2.0 Via: SIP/2.0/UDP 211.27.21.53:5060;rport;branch=z9hG4bK9272f7391fe31ef5ee55daf1de80eb75 Route: <sip:203.160.8.74;ftag=af53c7f79391b701;lr> From: 61280022329 <sip:61280022329@isphone.com.au>;tag=af53c7f79391b701 To: <sip:61296677152@203.160.8.74> Call-ID: 7183d5641f92f6934532a394197975ad@211.27.21.53 CSeq: 1654008671 ACK Max-Forwards: 70 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE Content-Length: 0 5408990mS SIP Tx: UDP 211.27.21.53:5060 -> 203.160.8.74:5060 ACK sip:61296677152@203.160.8.74 SIP/2.0 Via: SIP/2.0/UDP 211.27.21.53:5060;rport;branch=z9hG4bK9272f7391fe31ef5ee55daf1de80eb75 Route: <sip:203.160.8.74;ftag=af53c7f79391b701;lr> From: 61280022329 <sip:61280022329@isphone.com.au>;tag=af53c7f79391b701 To: <sip:61296677152@203.160.8.74> Call-ID: 7183d5641f92f6934532a394197975ad@211.27.21.53 CSeq: 1654008671 ACK Max-Forwards: 70 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE Content-Length: 0 5408991mS 5408991mS 5408991mS 5408991mS 5408991mS 5408991mS SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo: ********************************************************* State Transtion form Old State 17 to New state 9 ********************************************************* ********************************************************* MZ: INVITE SENT TO 203.160.8.74 5060 *********************************************************

Page 110 of 133

5408992mS SipDebugInfo: building authorisation header .... 5408993mS SipDebugInfo: MZ: Entered Sip_sendToNetwork packet destination is 203.160.8.74 5408994mS SipDebugInfo: MZ SIPTrunk SendToTarget cba0084a, 5060 5408994mS SIP Trunk: 12:Tx INVITE sip:61296677152@203.160.8.74 SIP/2.0 Via: SIP/2.0/UDP 211.27.21.53:5060;rport;branch=z9hG4bKeb5fcef9f3db6217890dae0145de5243 Route: <sip:203.160.8.74;ftag=af53c7f79391b701;lr> From: 61280022329 <sip:61280022329@isphone.com.au>;tag=af53c7f79391b701 To: <sip:61296677152@203.160.8.74> Call-ID: 7183d5641f92f6934532a394197975ad@211.27.21.53 CSeq: 1654008672 INVITE Contact: 61280022329 <sip:61280022329@211.27.21.53:5060;transport=udp> Max-Forwards: 70 Authorization: Digest username="61280022329",realm="203.160.8.74",nonce="c42dafb95f7971fd1db192d2fe141fe6457f66e9",response="79f4fb451dd8ac 6ca06d7430dd640c72",uri="sip:61296677152@203.160.8.74" Content-Type: application/sdp Content-Length: 300 v=0 o=UserA 105622857 1976233742 IN IP4 211.27.21.53 s=Session SDP c=IN IP4 211.27.21.53 t=0 0 m=audio 49152 RTP/AVP 18 4 8 0 101 a=rtpmap:18 G729/8000 a=rtpmap:4 G723/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:0 PCMU/8000 a=fmtp:18 annexb = no a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 5408994mS SIP Tx: UDP 211.27.21.53:5060 -> 203.160.8.74:5060 INVITE sip:61296677152@203.160.8.74 SIP/2.0 Via: SIP/2.0/UDP 211.27.21.53:5060;rport;branch=z9hG4bKeb5fcef9f3db6217890dae0145de5243 Route: <sip:203.160.8.74;ftag=af53c7f79391b701;lr> From: 61280022329 <sip:61280022329@isphone.com.au>;tag=af53c7f79391b701 To: <sip:61296677152@203.160.8.74> Call-ID: 7183d5641f92f6934532a394197975ad@211.27.21.53 CSeq: 1654008672 INVITE Contact: 61280022329 <sip:61280022329@211.27.21.53:5060;transport=udp> Max-Forwards: 70 Authorization: Digest username="61280022329",realm="203.160.8.74",nonce="c42dafb95f7971fd1db192d2fe141fe6457f66e9",response="79f4fb451dd8ac 6ca06d7430dd640c72",uri="sip:61296677152@203.160.8.74" Content-Type: application/sdp Content-Length: 300 v=0 o=UserA 105622857 1976233742 IN IP4 211.27.21.53 s=Session SDP c=IN IP4 211.27.21.53 t=0 0 m=audio 49152 RTP/AVP 18 4 8 0 101 a=rtpmap:18 G729/8000 a=rtpmap:4 G723/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:0 PCMU/8000 a=fmtp:18 annexb = no a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 SipDebugInfo: ********************************************************* SipDebugInfo: State Transtion form Old State 9 to New state 4 SipDebugInfo: ********************************************************* SipDebugInfo: SipTrunks: Cannot free Txn Key 2015 SIP Rx: UDP 203.160.8.74:5060 -> 211.27.21.53:5060 SIP/2.0 100 trying -- your call is important to us Via: SIP/2.0/UDP 211.27.21.53:5060;rport=5060;branch=z9hG4bKeb5fcef9f3db6217890dae0145de5243

5408995mS 5408995mS 5408995mS 5408995mS 5409261mS

Page 111 of 133

From: 61280022329 <sip:61280022329@isphone.com.au>;tag=af53c7f79391b701 To: <sip:61296677152@203.160.8.74> Call-ID: 7183d5641f92f6934532a394197975ad@211.27.21.53 CSeq: 1654008672 INVITE Server: Sip EXpress router (0.9.6 (i386/freebsd)) Content-Length: 0 5409262mS SIP Trunk: 12:Rx SIP/2.0 100 trying -- your call is important to us Via: SIP/2.0/UDP 211.27.21.53:5060;rport=5060;branch=z9hG4bKeb5fcef9f3db6217890dae0145de5243 From: 61280022329 <sip:61280022329@isphone.com.au>;tag=af53c7f79391b701 To: <sip:61296677152@203.160.8.74> Call-ID: 7183d5641f92f6934532a394197975ad@211.27.21.53 CSeq: 1654008672 INVITE Server: Sip EXpress router (0.9.6 (i386/freebsd)) Content-Length: 0 5409262mS 5409263mS 5409263mS 5409264mS 5409264mS 5409264mS 5409264mS 5409264mS 5409265mS 5409265mS 5409265mS 5410915mS SipDebugInfo: MZ SIPDialog: ReceiveFromTarget SipDebugInfo: MZ SIPDialog TXN : Decoding of message Succeded 1 SipDebugInfo: SIP: ProcessInbound Message SipDebugInfo: MZ Find End Point 7183d5641f92f6934532a394197975ad@211.27.21.53 SipDebugInfo: ProcessInboundSIPResponse SipDebugInfo: MZ SIPDialog No Tag due to error SipDebugInfo: ExtractRouteFromRecord, entered SipDebugInfo: ********************************************************* SipDebugInfo: State Transtion form Old State 4 to New state 5 SipDebugInfo: ********************************************************* SipDebugInfo: SipTrunks: Cannot free Txn Key 2015 SIP Rx: UDP 203.160.8.74:5060 -> 211.27.21.53:5060 SIP/2.0 180 Ringing Via: SIP/2.0/UDP 211.27.21.53:5060;rport=5060;branch=z9hG4bKeb5fcef9f3db6217890dae0145de5243 Record-Route: <sip:203.160.8.74;ftag=af53c7f79391b701;lr> From: 61280022329 <sip:61280022329@isphone.com.au>;tag=af53c7f79391b701 To: <sip:61296677152@203.160.8.74>;tag=240689c376cae9623edbbf57954b2521 Call-ID: 7183d5641f92f6934532a394197975ad@211.27.21.53 CSeq: 1654008672 INVITE Server: Sippy 5410915mS SIP Trunk: 12:Rx SIP/2.0 180 Ringing Via: SIP/2.0/UDP 211.27.21.53:5060;rport=5060;branch=z9hG4bKeb5fcef9f3db6217890dae0145de5243 Record-Route: <sip:203.160.8.74;ftag=af53c7f79391b701;lr> From: 61280022329 <sip:61280022329@isphone.com.au>;tag=af53c7f79391b701 To: <sip:61296677152@203.160.8.74>;tag=240689c376cae9623edbbf57954b2521 Call-ID: 7183d5641f92f6934532a394197975ad@211.27.21.53 CSeq: 1654008672 INVITE Server: Sippy 5410915mS 5410917mS 5410917mS 5410917mS 5410917mS 5410918mS 5410918mS 5410919mS 5412222mS SipDebugInfo: MZ SIPDialog: ReceiveFromTarget SipDebugInfo: MZ SIPDialog TXN : Decoding of message Succeded 1 SipDebugInfo: SIP: ProcessInbound Message SipDebugInfo: MZ Find End Point 7183d5641f92f6934532a394197975ad@211.27.21.53 SipDebugInfo: ProcessInboundSIPResponse SipDebugInfo: ExtractRouteFromRecord, entered SipDebugInfo: ProcessInboundSIPResponse: No Remote Tone SipDebugInfo: SipTrunks: Cannot free Txn Key 2015 SIP Rx: UDP 203.160.8.74:5060 -> 211.27.21.53:5060 SIP/2.0 200 OK Via: SIP/2.0/UDP 211.27.21.53:5060;rport=5060;branch=z9hG4bKeb5fcef9f3db6217890dae0145de5243 Record-Route: <sip:203.160.8.74;ftag=af53c7f79391b701;lr> From: 61280022329 <sip:61280022329@isphone.com.au>;tag=af53c7f79391b701 To: <sip:61296677152@203.160.8.74>;tag=240689c376cae9623edbbf57954b2521 Call-ID: 7183d5641f92f6934532a394197975ad@211.27.21.53 CSeq: 1654008672 INVITE Server: Sippy Contact: Anonymous <sip:203.160.8.74:5061> Content-Length: 204 Content-Type: application/sdp

Page 112 of 133

v=0 o=Sippy 142412652 1 IN IP4 203.160.8.74 s=VoipCall t=0 0 m=audio 10602 RTP/AVP 18 101 c=IN IP4 203.160.8.65 a=rtpmap:18 g729/8000/1 a=ptime:20 a=rtpmap:101 telephone-event/8000/1 a=sendrecv 5412225mS 5412225mS 5412225mS 5412225mS 5412226mS 5412226mS 5412226mS 5412226mS 5412226mS 5412228mS SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo: MZ SIPDialog TXN : Decoding of message Succeded 1 SIP: ProcessInbound Message MZ Find End Point 7183d5641f92f6934532a394197975ad@211.27.21.53 ProcessInboundSIPResponse ExtractRouteFromRecord, entered SIPDialog::UpdateSDPState has just transitioned to state 4 ********************************************************* MZ: ACK SENT TO 203.160.8.74 5060 ********************************************************* MZ: Entered Sip_sendToNetwork packet destination is 203.160.8.74

5412228mS SipDebugInfo: MZ SIPTrunk SendToTarget cba0084a, 5060 5412228mS SIP Trunk: 12:Tx ACK sip:203.160.8.74:5061 SIP/2.0 Via: SIP/2.0/UDP 211.27.21.53:5060;rport;branch=z9hG4bKeb5fcef9f3db6217890dae0145de5243 Route: <sip:203.160.8.74;ftag=af53c7f79391b701;lr> From: 61280022329 <sip:61280022329@isphone.com.au>;tag=af53c7f79391b701 To: <sip:61296677152@203.160.8.74>;tag=240689c376cae9623edbbf57954b2521 Call-ID: 7183d5641f92f6934532a394197975ad@211.27.21.53 CSeq: 1654008672 ACK Max-Forwards: 70 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE Content-Length: 0 5412228mS SIP Tx: UDP 211.27.21.53:5060 -> 203.160.8.74:5060 ACK sip:203.160.8.74:5061 SIP/2.0 Via: SIP/2.0/UDP 211.27.21.53:5060;rport;branch=z9hG4bKeb5fcef9f3db6217890dae0145de5243 Route: <sip:203.160.8.74;ftag=af53c7f79391b701;lr> From: 61280022329 <sip:61280022329@isphone.com.au>;tag=af53c7f79391b701 To: <sip:61296677152@203.160.8.74>;tag=240689c376cae9623edbbf57954b2521 Call-ID: 7183d5641f92f6934532a394197975ad@211.27.21.53 CSeq: 1654008672 ACK Max-Forwards: 70 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE Content-Length: 0 5412229mS SipDebugInfo: ProcessInboundSIPResponse: Cannot Get Address From Connection Header 2012 5412229mS SipDebugInfo: SIPDialog::SendCMMessageFromSDP: 4 attribute fields 5412232mS SipDebugInfo: ******************CMMessage received 11 5412233mS SipDebugInfo: SDP Outcome is : 1 5412233mS SipDebugInfo: ********************************************************* 5412233mS SipDebugInfo: State Transtion form Old State 5 to New state 16 5412233mS SipDebugInfo: ********************************************************* 5412233mS SipDebugInfo: SIPDialog::UpdateSDPState has just transitioned to state 7 5412233mS SipDebugInfo: ********************************************************* 5412233mS SipDebugInfo: State Transtion form Old State 16 to New state 16 5412233mS SipDebugInfo: ********************************************************* 5412234mS SipDebugInfo: SipTrunks: Cannot free Txn Key 2015 5412235mS PRN: SetRfc2833 (1): rx payload 101 tx payload 101 5412235mS PRN: SetRfc2833 (1): rx payload 101 tx payload 101 5412236mS PRN: SetRfc2833 (1): rx payload 101 tx payload 101 5415376mS SIP Rx: UDP 203.160.8.74:5060 -> 211.27.21.53:5060 BYE sip:61280022329@211.27.21.53:5060;transport=udp SIP/2.0 Via: SIP/2.0/UDP 203.160.8.74;branch=z9hG4bKdc9c.d16c65ec11ea3776318632d730027476.0 Via: SIP/2.0/UDP 203.160.8.74:5061;branch=z9hG4bK7d24547490b7a9a76d43ed781c84d258;rport=5061 Max-Forwards: 16

Page 113 of 133

From: <sip:61296677152@203.160.8.74>;tag=240689c376cae9623edbbf57954b2521 To: 61280022329 <sip:61280022329@isphone.com.au>;tag=af53c7f79391b701 Call-ID: 7183d5641f92f6934532a394197975ad@211.27.21.53 CSeq: 100 BYE Contact: Anonymous <sip:203.160.8.74:5061> Expires: 300 User-Agent: Sippy cisco-GUID: 1281594991-62460086-222525372-342785982 h323-conf-id: 1281594991-62460086-222525372-342785982 5415376mS SIP Trunk: 12:Rx BYE sip:61280022329@211.27.21.53:5060;transport=udp SIP/2.0 Via: SIP/2.0/UDP 203.160.8.74;branch=z9hG4bKdc9c.d16c65ec11ea3776318632d730027476.0 Via: SIP/2.0/UDP 203.160.8.74:5061;branch=z9hG4bK7d24547490b7a9a76d43ed781c84d258;rport=5061 Max-Forwards: 16 From: <sip:61296677152@203.160.8.74>;tag=240689c376cae9623edbbf57954b2521 To: 61280022329 <sip:61280022329@isphone.com.au>;tag=af53c7f79391b701 Call-ID: 7183d5641f92f6934532a394197975ad@211.27.21.53 CSeq: 100 BYE Contact: Anonymous <sip:203.160.8.74:5061> Expires: 300 User-Agent: Sippy cisco-GUID: 1281594991-62460086-222525372-342785982 h323-conf-id: 1281594991-62460086-222525372-342785982 5415376mS 5415378mS 5415379mS 5415379mS 5415379mS 5415379mS 5415379mS 5415380mS 5415380mS SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo: MZ SIPDialog: ReceiveFromTarget MZ SIPDialog TXN : Decoding of message Succeded 1 SIP: ProcessInbound Message MZ Find End Point 7183d5641f92f6934532a394197975ad@211.27.21.53 Process SIP request BYE Cannot Clone, message does not exist !!!!!!! SendSIPResponse SendSIPResponse, Number of Tag Count, 1 MZ: Entered Sip_sendToNetwork packet destination is 203.160.8.74

5415380mS SipDebugInfo: MZ SIPTrunk SendToTarget cba0084a, 5060 5415380mS SIP Trunk: 12:Tx SIP/2.0 200 Ok Via: SIP/2.0/UDP 203.160.8.74;branch=z9hG4bKdc9c.d16c65ec11ea3776318632d730027476.0 Via: SIP/2.0/UDP 203.160.8.74:5061;branch=z9hG4bK7d24547490b7a9a76d43ed781c84d258;rport=5061 From: <sip:61296677152@203.160.8.74>;tag=240689c376cae9623edbbf57954b2521 To: 61280022329 <sip:61280022329@isphone.com.au>;tag=af53c7f79391b701 Call-ID: 7183d5641f92f6934532a394197975ad@211.27.21.53 CSeq: 100 BYE Content-Length: 0 5415381mS SIP Tx: UDP 211.27.21.53:5060 -> 203.160.8.74:5060 SIP/2.0 200 Ok Via: SIP/2.0/UDP 203.160.8.74;branch=z9hG4bKdc9c.d16c65ec11ea3776318632d730027476.0 Via: SIP/2.0/UDP 203.160.8.74:5061;branch=z9hG4bK7d24547490b7a9a76d43ed781c84d258;rport=5061 From: <sip:61296677152@203.160.8.74>;tag=240689c376cae9623edbbf57954b2521 To: 61280022329 <sip:61280022329@isphone.com.au>;tag=af53c7f79391b701 Call-ID: 7183d5641f92f6934532a394197975ad@211.27.21.53 CSeq: 100 BYE Content-Length: 0 5415381mS 5415381mS 5415381mS 5415383mS 5415384mS 5415384mS 5415384mS SipDebugInfo: ********************************************************* SipDebugInfo: State Transtion form Old State 16 to New state 22 SipDebugInfo: ********************************************************* SipDebugInfo: Call Lost is entered casue is 16, state is 23 SipDebugInfo: SIPDialog destructor ... SipDebugInfo: SIPDialog - Free SDPBody.... SipDebugInfo: Call Lost is about to delete endpoint

Page 114 of 133

Engin Configuration The testing was conducted on 4.0 Pre Release Notes: Engin do not require the number to be presented to them in International format Engin SIP account can be accessed from any public accessible device Providing authentication retails are provided in the call set-up The ARS or System Short code must be in the format 029N"@byo.engin.com.au" not 029N"@202.61.13.40" In the SIP Invite this will make the from field to be the correct format
From: 0282130845 <sip:0282130845@byo.engin.com.au>;tag=516006184bf3f8a4

Details we were given from the carrier Username and also incoming number: 0282130845 Password: XXXXXX (Hidden for Security Reasons) Sip server: byo.engin.com.au which resolves to 202.61.13.40 See blow reflection of IP Office Settings on Line 13

Page 115 of 133

We gave the Line Incoming and Outgoing Group 252 All Local URI, Contact and Display names were set to Use Authentication Name See below ARS configuration including SIP Short code for 9 numbers Note the specific Short code with domain name

Page 116 of 133

See below Sys-Monitor trace of Extension 210 to 96677152 via SIP Line 252 as per ARS above
788250mS 788250mS 788250mS 788250mS 788250mS 788251mS 788251mS 788251mS 788251mS 788254mS 788254mS 788254mS 788254mS 788254mS 788256mS 788256mS 788256mS 788256mS SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo: SIPTrunks: Make Target voip, line group id is 252 and ip SIPTrunks cannot find a suitable SIP URI to dial out SIPTrunks: Make Target voip, line group id is 252 and ip SIPTrunks cannot find a suitable SIP URI to dial out SIPTrunks: Make Target voip, line group id is 252 and ip SIPTrunks cannot find a suitable SIP URI to dial out SIPTrunks: Make Target voip, line group id is 252 and ip SIPTrunks: active channels 0 overall number 10 License, Valid 1, Available 255, Consumed 0 MZ extension is dialing 0296677152@byo.engin.com.au of cba667f2 of 7dfe1902 of cba0084a of ca3d0d28

MZ extension is dialing 0296677152@byo.engin.com.au ********************************************************* MZ: INVITE (method) SENT TO 202.61.13.40 5060 ********************************************************* ********************************************************* MZ: INVITE SENT TO 202.61.13.40 5060 ********************************************************* MZ: Entered Sip_sendToNetwork packet destination is 202.61.13.40

788257mS SipDebugInfo: MZ SIPTrunk SendToTarget ca3d0d28, 5060 788257mS SIP Trunk: 13:Tx INVITE sip:0296677152@byo.engin.com.au SIP/2.0 Via: SIP/2.0/UDP 211.27.21.53:5060;rport;branch=z9hG4bKedacc4f13b8d4daff72178056f35d3f5 From: 0282130845 <sip:0282130845@byo.engin.com.au>;tag=516006184bf3f8a4 To: <sip:0296677152@byo.engin.com.au> Call-ID: 812a7924a0b3558f375663b9ec87fcfa@211.27.21.53 CSeq: 2121869255 INVITE Contact: 0282130845 <sip:0282130845@211.27.21.53:5060;transport=udp> Max-Forwards: 70 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE Content-Type: application/sdp Content-Length: 301 v=0 o=UserA 1847263294 2974457633 IN IP4 211.27.21.53 s=Session SDP c=IN IP4 211.27.21.53 t=0 0 m=audio 49152 RTP/AVP 18 4 8 0 101 a=rtpmap:18 G729/8000 a=rtpmap:4 G723/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:0 PCMU/8000 a=fmtp:18 annexb = no a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 788257mS SIP Tx: UDP 211.27.21.53:5060 -> 202.61.13.40:5060 INVITE sip:0296677152@byo.engin.com.au SIP/2.0 Via: SIP/2.0/UDP 211.27.21.53:5060;rport;branch=z9hG4bKedacc4f13b8d4daff72178056f35d3f5 From: 0282130845 <sip:0282130845@byo.engin.com.au>;tag=516006184bf3f8a4 To: <sip:0296677152@byo.engin.com.au> Call-ID: 812a7924a0b3558f375663b9ec87fcfa@211.27.21.53 CSeq: 2121869255 INVITE Contact: 0282130845 <sip:0282130845@211.27.21.53:5060;transport=udp> Max-Forwards: 70 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE Content-Type: application/sdp Content-Length: 301 v=0 o=UserA 1847263294 2974457633 IN IP4 211.27.21.53 s=Session SDP c=IN IP4 211.27.21.53 t=0 0 m=audio 49152 RTP/AVP 18 4 8 0 101

Page 117 of 133

788258mS 788258mS 788258mS 788258mS 788258mS 788405mS

a=rtpmap:18 G729/8000 a=rtpmap:4 G723/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:0 PCMU/8000 a=fmtp:18 annexb = no a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 SipDebugInfo: initialising mTxnContext SipDebugInfo: ********************************************************* SipDebugInfo: State Transtion form Old State 0 to New state 1 SipDebugInfo: ********************************************************* SipDebugInfo: SIPDialog::UpdateSDPState has just transitioned to state 1 SIP Rx: UDP 202.61.13.40:5060 -> 211.27.21.53:5060 SIP/2.0 100 Trying To: <sip:0296677152@byo.engin.com.au> From: 0282130845<sip:0282130845@byo.engin.com.au>;tag=516006184bf3f8a4 Via: SIP/2.0/UDP 211.27.21.53:5060;branch=z9hG4bKedacc4f13b8d4daff72178056f35d3f5 Call-ID: 812a7924a0b3558f375663b9ec87fcfa@211.27.21.53 CSeq: 2121869255 INVITE Server: DITC-PeerPoint C100/3-05-26-GA7p1 Content-Length: 0

788406mS SIP Trunk: 13:Rx SIP/2.0 100 Trying To: <sip:0296677152@byo.engin.com.au> From: 0282130845<sip:0282130845@byo.engin.com.au>;tag=516006184bf3f8a4 Via: SIP/2.0/UDP 211.27.21.53:5060;branch=z9hG4bKedacc4f13b8d4daff72178056f35d3f5 Call-ID: 812a7924a0b3558f375663b9ec87fcfa@211.27.21.53 CSeq: 2121869255 INVITE Server: DITC-PeerPoint C100/3-05-26-GA7p1 Content-Length: 0 788406mS 788407mS 788407mS 788408mS 788408mS 788408mS 788408mS 788410mS 788410mS 788410mS 788410mS 788649mS SipDebugInfo: MZ SIPDialog: ReceiveFromTarget SipDebugInfo: MZ SIPDialog TXN : Decoding of message Succeded 1 SipDebugInfo: SIP: ProcessInbound Message SipDebugInfo: MZ Find End Point 812a7924a0b3558f375663b9ec87fcfa@211.27.21.53 SipDebugInfo: ProcessInboundSIPResponse SipDebugInfo: MZ SIPDialog No Tag due to error SipDebugInfo: ExtractRouteFromRecord, entered SipDebugInfo: ********************************************************* SipDebugInfo: State Transtion form Old State 1 to New state 5 SipDebugInfo: ********************************************************* SipDebugInfo: SipTrunks: Cannot free Txn Key 2015 SIP Rx: UDP 202.61.13.40:5060 -> 211.27.21.53:5060

SIP/2.0 407 Proxy Authentication Required To: <sip:0296677152@voice.mibroadband.com.au>;tag=b0a7f65d From: 0282130845<sip:0282130845@voice.mibroadband.com.au>;tag=516006184bf3f8a4 Via: SIP/2.0/UDP 211.27.21.53:5060;branch=z9hG4bKedacc4f13b8d4daff72178056f35d3f5 Call-ID: 812a7924a0b3558f375663b9ec87fcfa@211.27.21.53 CSeq: 2121869255 INVITE Proxy-Authenticate: Digest realm="mobileinnovations.com.au",domain="sip:0296677152@byo.engin.com.au",nonce="wY2GQnKHdWsBtaz1tHZ6vg==_37977",qo p="auth" Content-Length: 0 788650mS SIP Trunk: 13:Rx SIP/2.0 407 Proxy Authentication Required To: <sip:0296677152@voice.mibroadband.com.au>;tag=b0a7f65d From: 0282130845<sip:0282130845@voice.mibroadband.com.au>;tag=516006184bf3f8a4 Via: SIP/2.0/UDP 211.27.21.53:5060;branch=z9hG4bKedacc4f13b8d4daff72178056f35d3f5 Call-ID: 812a7924a0b3558f375663b9ec87fcfa@211.27.21.53 CSeq: 2121869255 INVITE Proxy-Authenticate: Digest realm="mobileinnovations.com.au",domain="sip:0296677152@byo.engin.com.au",nonce="wY2GQnKHdWsBtaz1tHZ6vg==_37977",qo p="auth" Content-Length: 0 788650mS SipDebugInfo: MZ SIPDialog: ReceiveFromTarget 788652mS SipDebugInfo: MZ SIPDialog TXN : Decoding of message Succeded 1

Page 118 of 133

788652mS 788652mS 788652mS 788652mS 788653mS 788653mS 788653mS 788653mS 788653mS 788653mS 788653mS 788654mS 788654mS 788654mS 788654mS 788654mS 788654mS 788654mS 788655mS

SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo:

SIP: ProcessInbound Message MZ Find End Point 812a7924a0b3558f375663b9ec87fcfa@211.27.21.53 ProcessInboundSIPResponse ExtractRouteFromRecord, entered ExtractContactFromMessage: cannot get From Header 2012 MZ SIP-EP: Decoding of 407 (challenge) RESPONSE ProcessAuthenticationRequired: proxy is Digest ProcessWWWAuthenticationRequired: Number of Challange Param is 4 ProcessWWWAuthenticationRequired: realm is "mobileinnovations.com.au" ProcessWWWAuthenticationRequired: realm length 26 ProcessWWWAuthenticationRequired: nonce is "wY2GQnKHdWsBtaz1tHZ6vg==_37977" ProcessWWWAuthenticationRequired: nonce lentgh 32 ********************************************************* State Transtion form Old State 5 to New state 17 ********************************************************* ********************************************************* MZ: ACK SENT TO 202.61.13.40 5060 ********************************************************* MZ: Entered Sip_sendToNetwork packet destination is 202.61.13.40

788656mS SipDebugInfo: MZ SIPTrunk SendToTarget ca3d0d28, 5060 788656mS SIP Trunk: 13:Tx ACK sip:0296677152@byo.engin.com.au SIP/2.0 Via: SIP/2.0/UDP 211.27.21.53:5060;rport;branch=z9hG4bKedacc4f13b8d4daff72178056f35d3f5 From: 0282130845 <sip:0282130845@byo.engin.com.au>;tag=516006184bf3f8a4 To: <sip:0296677152@byo.engin.com.au>;tag=b0a7f65d Call-ID: 812a7924a0b3558f375663b9ec87fcfa@211.27.21.53 CSeq: 2121869255 ACK Max-Forwards: 70 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE Content-Length: 0 788656mS SIP Tx: UDP 211.27.21.53:5060 -> 202.61.13.40:5060 ACK sip:0296677152@byo.engin.com.au SIP/2.0 Via: SIP/2.0/UDP 211.27.21.53:5060;rport;branch=z9hG4bKedacc4f13b8d4daff72178056f35d3f5 From: 0282130845 <sip:0282130845@byo.engin.com.au>;tag=516006184bf3f8a4 To: <sip:0296677152@byo.engin.com.au>;tag=b0a7f65d Call-ID: 812a7924a0b3558f375663b9ec87fcfa@211.27.21.53 CSeq: 2121869255 ACK Max-Forwards: 70 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE Content-Length: 0 788657mS 788657mS 788657mS 788657mS 788657mS 788657mS 788658mS 788659mS SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo: ********************************************************* State Transtion form Old State 17 to New state 9 ********************************************************* ********************************************************* MZ: INVITE SENT TO 202.61.13.40 5060 ********************************************************* building authorisation header .... MZ: Entered Sip_sendToNetwork packet destination is 202.61.13.40

788659mS SipDebugInfo: MZ SIPTrunk SendToTarget ca3d0d28, 5060 788659mS SIP Trunk: 13:Tx INVITE sip:0296677152@byo.engin.com.au SIP/2.0 Via: SIP/2.0/UDP 211.27.21.53:5060;rport;branch=z9hG4bK8d720ac532d5fa78c4664a99fe273ec3 From: 0282130845 <sip:0282130845@byo.engin.com.au>;tag=516006184bf3f8a4 To: <sip:0296677152@byo.engin.com.au> Call-ID: 812a7924a0b3558f375663b9ec87fcfa@211.27.21.53 CSeq: 2121869256 INVITE Contact: 0282130845 <sip:0282130845@211.27.21.53:5060;transport=udp> Max-Forwards: 70 Proxy-Authorization: Digest username="0282130845",realm="mobileinnovations.com.au",nonce="wY2GQnKHdWsBtaz1tHZ6vg==_37977",response="df68896ac8 8c6f81c7e0610a3fde307d",uri="sip:0296677152@byo.engin.com.au" Content-Type: application/sdp Content-Length: 301 v=0 o=UserA 1847263294 2974457634 IN IP4 211.27.21.53

Page 119 of 133

s=Session SDP c=IN IP4 211.27.21.53 t=0 0 m=audio 49152 RTP/AVP 18 4 8 0 101 a=rtpmap:18 G729/8000 a=rtpmap:4 G723/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:0 PCMU/8000 a=fmtp:18 annexb = no a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 788660mS SIP Tx: UDP 211.27.21.53:5060 -> 202.61.13.40:5060 INVITE sip:0296677152@byo.engin.com.au SIP/2.0 Via: SIP/2.0/UDP 211.27.21.53:5060;rport;branch=z9hG4bK8d720ac532d5fa78c4664a99fe273ec3 From: 0282130845 <sip:0282130845@byo.engin.com.au>;tag=516006184bf3f8a4 To: <sip:0296677152@byo.engin.com.au> Call-ID: 812a7924a0b3558f375663b9ec87fcfa@211.27.21.53 CSeq: 2121869256 INVITE Contact: 0282130845 <sip:0282130845@211.27.21.53:5060;transport=udp> Max-Forwards: 70 Proxy-Authorization: Digest username="0282130845",realm="mobileinnovations.com.au",nonce="wY2GQnKHdWsBtaz1tHZ6vg==_37977",response="df68896ac8 8c6f81c7e0610a3fde307d",uri="sip:0296677152@byo.engin.com.au" Content-Type: application/sdp Content-Length: 301 v=0 o=UserA 1847263294 2974457634 IN IP4 211.27.21.53 s=Session SDP c=IN IP4 211.27.21.53 t=0 0 m=audio 49152 RTP/AVP 18 4 8 0 101 a=rtpmap:18 G729/8000 a=rtpmap:4 G723/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:0 PCMU/8000 a=fmtp:18 annexb = no a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 SipDebugInfo: ********************************************************* SipDebugInfo: State Transtion form Old State 9 to New state 4 SipDebugInfo: ********************************************************* SipDebugInfo: SipTrunks: Cannot free Txn Key 2015 SIP Rx: UDP 202.61.13.40:5060 -> 211.27.21.53:5060 SIP/2.0 100 Trying To: <sip:0296677152@byo.engin.com.au> From: 0282130845<sip:0282130845@byo.engin.com.au>;tag=516006184bf3f8a4 Via: SIP/2.0/UDP 211.27.21.53:5060;branch=z9hG4bK8d720ac532d5fa78c4664a99fe273ec3 Call-ID: 812a7924a0b3558f375663b9ec87fcfa@211.27.21.53 CSeq: 2121869256 INVITE Server: DITC-PeerPoint C100/3-05-26-GA7p1 Content-Length: 0 788898mS SIP Trunk: 13:Rx SIP/2.0 100 Trying To: <sip:0296677152@byo.engin.com.au> From: 0282130845<sip:0282130845@byo.engin.com.au>;tag=516006184bf3f8a4 Via: SIP/2.0/UDP 211.27.21.53:5060;branch=z9hG4bK8d720ac532d5fa78c4664a99fe273ec3 Call-ID: 812a7924a0b3558f375663b9ec87fcfa@211.27.21.53 CSeq: 2121869256 INVITE Server: DITC-PeerPoint C100/3-05-26-GA7p1 Content-Length: 0 788898mS 788899mS 788900mS 788900mS 788900mS 788900mS SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo: MZ SIPDialog: ReceiveFromTarget MZ SIPDialog TXN : Decoding of message Succeded 1 SIP: ProcessInbound Message MZ Find End Point 812a7924a0b3558f375663b9ec87fcfa@211.27.21.53 ProcessInboundSIPResponse MZ SIPDialog No Tag due to error

788660mS 788661mS 788661mS 788661mS 788898mS

Page 120 of 133

788900mS 788901mS 788901mS 788901mS 788901mS 790760mS

SipDebugInfo: ExtractRouteFromRecord, entered SipDebugInfo: ********************************************************* SipDebugInfo: State Transtion form Old State 4 to New state 5 SipDebugInfo: ********************************************************* SipDebugInfo: SipTrunks: Cannot free Txn Key 2015 SIP Rx: UDP 202.61.13.40:5060 -> 211.27.21.53:5060 SIP/2.0 180 Ringing To: <sip:0296677152@voice.mibroadband.com.au>;tag=fe9f437f From: 0282130845<sip:0282130845@voice.mibroadband.com.au>;tag=516006184bf3f8a4 Via: SIP/2.0/UDP 211.27.21.53:5060;branch=z9hG4bK8d720ac532d5fa78c4664a99fe273ec3 Call-ID: 812a7924a0b3558f375663b9ec87fcfa@211.27.21.53 CSeq: 2121869256 INVITE Contact: <sip:0C7Z2psXivb_tdhTsGXHaY8gJy89-uwh8lGAufQ@202.61.13.40:5060> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER Date: Thu, 14 Dec 2006 04:33:48 GMT Server: Cisco-SIPGateway/IOS-12.x Allow-Events: telephone-event Content-Length: 0

790761mS SIP Trunk: 13:Rx SIP/2.0 180 Ringing To: <sip:0296677152@voice.mibroadband.com.au>;tag=fe9f437f From: 0282130845<sip:0282130845@voice.mibroadband.com.au>;tag=516006184bf3f8a4 Via: SIP/2.0/UDP 211.27.21.53:5060;branch=z9hG4bK8d720ac532d5fa78c4664a99fe273ec3 Call-ID: 812a7924a0b3558f375663b9ec87fcfa@211.27.21.53 CSeq: 2121869256 INVITE Contact: <sip:0C7Z2psXivb_tdhTsGXHaY8gJy89-uwh8lGAufQ@202.61.13.40:5060> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER Date: Thu, 14 Dec 2006 04:33:48 GMT Server: Cisco-SIPGateway/IOS-12.x Allow-Events: telephone-event Content-Length: 0 790761mS 790763mS 790763mS 790763mS 790763mS 790764mS 790764mS 790765mS 791687mS SipDebugInfo: MZ SIPDialog: ReceiveFromTarget SipDebugInfo: MZ SIPDialog TXN : Decoding of message Succeded 1 SipDebugInfo: SIP: ProcessInbound Message SipDebugInfo: MZ Find End Point 812a7924a0b3558f375663b9ec87fcfa@211.27.21.53 SipDebugInfo: ProcessInboundSIPResponse SipDebugInfo: ExtractRouteFromRecord, entered SipDebugInfo: ProcessInboundSIPResponse: No Remote Tone SipDebugInfo: SipTrunks: Cannot free Txn Key 2015 SIP Rx: UDP 202.61.13.40:5060 -> 211.27.21.53:5060 SIP/2.0 200 OK To: <sip:0296677152@voice.mibroadband.com.au>;tag=fe9f437f From: 0282130845<sip:0282130845@voice.mibroadband.com.au>;tag=516006184bf3f8a4 Via: SIP/2.0/UDP 211.27.21.53:5060;branch=z9hG4bK8d720ac532d5fa78c4664a99fe273ec3 Call-ID: 812a7924a0b3558f375663b9ec87fcfa@211.27.21.53 CSeq: 2121869256 INVITE Contact: <sip:0C7Z2psXivb_tdhTsGXHaY8gJy89-uwh8lGAufQ@202.61.13.40:5060> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER Content-Disposition: session;handling=required Content-Type: application/sdp Date: Thu, 14 Dec 2006 04:33:48 GMT Server: Cisco-SIPGateway/IOS-12.x Allow-Events: telephone-event Content-Length: 265 v=0 o=CiscoSystemsSIP-GW-UserAgent 9211 1094264623 IN IP4 202.61.13.40 s=SIP Call c=IN IP4 202.61.13.40 t=0 0 m=audio 18290 RTP/AVP 18 101 c=IN IP4 202.61.13.40 a=fmtp:18 annexb=yes a=fmtp:101 0-15 a=rtpmap:18 G729/8000 a=rtpmap:101 telephone-event/8000 791687mS SIP Trunk: 13:Rx

Page 121 of 133

SIP/2.0 200 OK To: <sip:0296677152@voice.mibroadband.com.au>;tag=fe9f437f From: 0282130845<sip:0282130845@voice.mibroadband.com.au>;tag=516006184bf3f8a4 Via: SIP/2.0/UDP 211.27.21.53:5060;branch=z9hG4bK8d720ac532d5fa78c4664a99fe273ec3 Call-ID: 812a7924a0b3558f375663b9ec87fcfa@211.27.21.53 CSeq: 2121869256 INVITE Contact: <sip:0C7Z2psXivb_tdhTsGXHaY8gJy89-uwh8lGAufQ@202.61.13.40:5060> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER Content-Disposition: session;handling=required Content-Type: application/sdp Date: Thu, 14 Dec 2006 04:33:48 GMT Server: Cisco-SIPGateway/IOS-12.x Allow-Events: telephone-event Content-Length: 265 v=0 o=CiscoSystemsSIP-GW-UserAgent 9211 1094264623 IN IP4 202.61.13.40 s=SIP Call c=IN IP4 202.61.13.40 t=0 0 m=audio 18290 RTP/AVP 18 101 c=IN IP4 202.61.13.40 a=fmtp:18 annexb=yes a=fmtp:101 0-15 a=rtpmap:18 G729/8000 a=rtpmap:101 telephone-event/8000 SipDebugInfo: MZ SIPDialog: ReceiveFromTarget SipDebugInfo: MZ SIPDialog TXN : Decoding of message Succeded 1 SipDebugInfo: SIP: ProcessInbound Message SipDebugInfo: MZ Find End Point 812a7924a0b3558f375663b9ec87fcfa@211.27.21.53 SipDebugInfo: ProcessInboundSIPResponse SipDebugInfo: ExtractRouteFromRecord, entered SipDebugInfo: SIPDialog::UpdateSDPState has just transitioned to state 4 SipDebugInfo: ********************************************************* SipDebugInfo: MZ: ACK SENT TO 202.61.13.40 5060 SipDebugInfo: ********************************************************* SipDebugInfo: MZ: Entered Sip_sendToNetwork packet destination is 202.61.13.40

791687mS 791690mS 791690mS 791691mS 791691mS 791691mS 791691mS 791692mS 791692mS 791692mS 791693mS

791693mS SipDebugInfo: MZ SIPTrunk SendToTarget ca3d0d28, 5060 791693mS SIP Trunk: 13:Tx ACK sip:0C7Z2psXivb_tdhTsGXHaY8gJy89-uwh8lGAufQ@202.61.13.40:5060 SIP/2.0 Via: SIP/2.0/UDP 211.27.21.53:5060;rport;branch=z9hG4bK8d720ac532d5fa78c4664a99fe273ec3 From: 0282130845 <sip:0282130845@byo.engin.com.au>;tag=516006184bf3f8a4 To: <sip:0296677152@byo.engin.com.au>;tag=fe9f437f Call-ID: 812a7924a0b3558f375663b9ec87fcfa@211.27.21.53 CSeq: 2121869256 ACK Max-Forwards: 70 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE Content-Length: 0 791693mS SIP Tx: UDP 211.27.21.53:5060 -> 202.61.13.40:5060 ACK sip:0C7Z2psXivb_tdhTsGXHaY8gJy89-uwh8lGAufQ@202.61.13.40:5060 SIP/2.0 Via: SIP/2.0/UDP 211.27.21.53:5060;rport;branch=z9hG4bK8d720ac532d5fa78c4664a99fe273ec3 From: 0282130845 <sip:0282130845@byo.engin.com.au>;tag=516006184bf3f8a4 To: <sip:0296677152@byo.engin.com.au>;tag=fe9f437f Call-ID: 812a7924a0b3558f375663b9ec87fcfa@211.27.21.53 CSeq: 2121869256 ACK Max-Forwards: 70 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE Content-Length: 0 791694mS SipDebugInfo: SIPDialog::SendCMMessageFromSDP: 4 attribute fields 791697mS SipDebugInfo: ******************CMMessage received 11 791698mS SipDebugInfo: SDP Outcome is : 1 791698mS SipDebugInfo: ********************************************************* 791698mS SipDebugInfo: State Transtion form Old State 5 to New state 16 791698mS SipDebugInfo: ********************************************************* 791698mS SipDebugInfo: SIPDialog::UpdateSDPState has just transitioned to state 7 791698mS SipDebugInfo: *********************************************************

Page 122 of 133

791698mS 791698mS 791699mS 793232mS

SipDebugInfo: State Transtion form Old State 16 to New state 16 SipDebugInfo: ********************************************************* SipDebugInfo: SipTrunks: Cannot free Txn Key 2015 SIP Rx: UDP 202.61.13.40:5060 -> 211.27.21.53:5060

BYE sip:0282130845@211.27.21.53:5060;transport=udp SIP/2.0 To: 0282130845<sip:0282130845@voice.mibroadband.com.au>;tag=516006184bf3f8a4 From: <sip:0296677152@voice.mibroadband.com.au>;tag=fe9f437f Via: SIP/2.0/UDP 202.61.13.40:5060;branch=z9hG4bK-d87543-5981e0239adf6822d8fd-1cHA5MTQ0Nzk3NTY1NDc4ZTY0MWY2OQ..-d87543Call-ID: 812a7924a0b3558f375663b9ec87fcfa@211.27.21.53 CSeq: 17308047 BYE Contact: <sip:0C7Z2psXivb_tdhTsGXHaY8gJy89-uwh8lGAufQ@202.61.13.40:5060> Max-Forwards: 68 Date: Thu, 14 Dec 2006 04:33:50 GMT Timestamp: 1166070832 User-Agent: Cisco-SIPGateway/IOS-12.x Content-Length: 0 Reason: Q.850;cause=16 793232mS SIP Trunk: 13:Rx BYE sip:0282130845@211.27.21.53:5060;transport=udp SIP/2.0 To: 0282130845<sip:0282130845@voice.mibroadband.com.au>;tag=516006184bf3f8a4 From: <sip:0296677152@voice.mibroadband.com.au>;tag=fe9f437f Via: SIP/2.0/UDP 202.61.13.40:5060;branch=z9hG4bK-d87543-5981e0239adf6822d8fd-1cHA5MTQ0Nzk3NTY1NDc4ZTY0MWY2OQ..-d87543Call-ID: 812a7924a0b3558f375663b9ec87fcfa@211.27.21.53 CSeq: 17308047 BYE Contact: <sip:0C7Z2psXivb_tdhTsGXHaY8gJy89-uwh8lGAufQ@202.61.13.40:5060> Max-Forwards: 68 Date: Thu, 14 Dec 2006 04:33:50 GMT Timestamp: 1166070832 User-Agent: Cisco-SIPGateway/IOS-12.x Content-Length: 0 Reason: Q.850;cause=16 793233mS 793235mS 793235mS 793235mS 793236mS 793236mS 793236mS 793236mS 793237mS SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo: MZ SIPDialog: ReceiveFromTarget MZ SIPDialog TXN : Decoding of message Succeded 1 SIP: ProcessInbound Message MZ Find End Point 812a7924a0b3558f375663b9ec87fcfa@211.27.21.53 Process SIP request BYE Cannot Clone, message does not exist !!!!!!! SendSIPResponse SendSIPResponse, Number of Tag Count, 1 MZ: Entered Sip_sendToNetwork packet destination is 202.61.13.40

793237mS SipDebugInfo: MZ SIPTrunk SendToTarget ca3d0d28, 5060 793237mS SIP Trunk: 13:Tx SIP/2.0 200 Ok Via: SIP/2.0/UDP 202.61.13.40:5060;branch=z9hG4bK-d87543-5981e0239adf6822d8fd-1cHA5MTQ0Nzk3NTY1NDc4ZTY0MWY2OQ..-d87543From: <sip:0296677152@voice.mibroadband.com.au>;tag=fe9f437f To: 0282130845 <sip:0282130845@voice.mibroadband.com.au>;tag=516006184bf3f8a4 Call-ID: 812a7924a0b3558f375663b9ec87fcfa@211.27.21.53 CSeq: 17308047 BYE Content-Length: 0 793237mS SIP Tx: UDP 211.27.21.53:5060 -> 202.61.13.40:5060 SIP/2.0 200 Ok Via: SIP/2.0/UDP 202.61.13.40:5060;branch=z9hG4bK-d87543-5981e0239adf6822d8fd-1cHA5MTQ0Nzk3NTY1NDc4ZTY0MWY2OQ..-d87543From: <sip:0296677152@voice.mibroadband.com.au>;tag=fe9f437f To: 0282130845 <sip:0282130845@voice.mibroadband.com.au>;tag=516006184bf3f8a4 Call-ID: 812a7924a0b3558f375663b9ec87fcfa@211.27.21.53 CSeq: 17308047 BYE Content-Length: 0 793238mS SipDebugInfo: ********************************************************* 793238mS SipDebugInfo: State Transtion form Old State 16 to New state 22 793238mS SipDebugInfo: *********************************************************

Page 123 of 133

793240mS 793240mS 793240mS 793241mS 793242mS

SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo: SipDebugInfo:

Call Lost is entered casue is 16, state is 23 SIPDialog destructor ... SIPDialog - Free SDPBody.... Call Lost is about to delete endpoint SipTrunks: Freed Txn Key 2016

Page 124 of 133

19, Other

Useful SIP related Information

SIP Response Codes SIP response codes, class 1: Provisional messages These are sent within a SIP dialogue 100 Trying 180 Ringing 181 Call Is Being Forwarded 182 Queued 183 Session Progress

SIP Response codes: 2xx class The 2xx class of responses indicates a success 200 OK 202 accepted: Used for referrals

SIP response codes, class 3xx The 3xx class of responses indicates a redirection of the call 300 Multiple Choices 301 Moved Permanently 302 Moved Temporarily 305 Use Proxy 380 Alternative Service SIP responses, class 4: Request failures 400 Bad Request 401 Unauthorized: Used only by registrars. Proxys should use proxy authorization 407 402 Payment Required (Reserved for future use) 403 Forbidden 404 Not Found: User not found 405 Method Not Allowed 406 Not Acceptable 407 Proxy Authentication Required 408 Request Timeout: Couldn't find the user in time 410 Gone: The user existed once, but is not available here any more. 413 Request Entity Too Large 414 Request-URI Too Long

Page 125 of 133

415 Unsupported Media Type 416 Unsupported URI Scheme 420 Bad Extension: Bad SIP Protocol Extension used, not understood by the server 421 Extension Required 423 Interval Too Brief 480 Temporarily Unavailable 481 Call/Transaction Does Not Exist 482 Loop Detected 483 Too Many Hops 484 Address Incomplete 485 Ambiguous 486 Busy Here 487 Request Terminated 488 Not Acceptable Here 491 Request Pending 493 Undecipherable: Could not decrypt S/MIME body part SIP responses, class 5: Server failures 500 Server Internal Error 501 Not Implemented: The SIP request method is not implemented here 502 Bad Gateway 503 Service Unavailable 504 Server Time-out 505 Version Not Supported: The server does not support this version of the SIP protocol 513 Message Too Large SIP response codes, class 6: Global failures 600 Busy Everywhere 603 Decline 604 Does Not Exist Anywhere 606 Not Acceptable

Page 126 of 133

Sample SIP Transactions Register Transaction The UA sends a REGISTER message to the Registrar. The REGISTER message contains the UA's SIP URI and the current contact address from which the UA is registering. The Registrar responds with a 200 OK response.

Session Invitation and Termination Transactions

In the transactions above, a UA sends an INVITE request to another UA via a proxy. The proxy immediately replies with a 100 TRYING response, and then forwards the INVITE on to the called UA. (Note that the requests and responses may actually traverse several proxies, which are not shown in the diagram for the purpose of simplification.) The called UA sends a 180 RINGING response back through the proxy, followed by a 200 OK response. The calling UA receives the 200 OK and responds with an ACK message. Then, a direct media stream is established between the UAs, using RTP or another media transport protocol. From this point on, the UAs communicate directly without going through a proxy (although any proxy in the initial signalling path can choose to remain in the signalling path for the rest of the call).

Page 127 of 133

Event Subscription and Notification Transactions User Agents use the SUBSCRIBE message to request current state information (presence) about another User Agent. After the User Agent sends a SUBCRIBE request, the proxy replies with a 200 OK followed by a NOTIFY. The User Agent replies with a 200 OK. After that point, the proxy sends a NOTIFY any time there is a change in status of the event to which the user has subscribed.

Instant Message Transactions User Agent A sends a MESSAGE request through a proxy to establish an instant messaging session. The actual message text is included in the body of the MESSAGE request. User Agent B responds with a 200 OK, and then sends a MESSAGE request with IM text. User Agent A responds with a 200 OK.

Page 128 of 133

1, Reseller - Customer information Reseller Details Company Name: Contact Name: Contact Number: Customer Details Company Name: Contact Name: Contact Number: Proposal/Tender/Quote Ref No: 2, Voice Related Brief Questions 1. a. How many concurrent calls will be required to cross the link between sites at any given point in time? (info required for bandwidth allocations/reserves) See Technical Notes for further information b. Which sites will be connected via this link(s)? Enter the Resellers Details here Enter the Resellers Contact Details Here Enter the Resellers Contact Details Here Enter the End User Details Here (Optional) Enter the End User Contact Details Here (Optional) Enter the Resellers Contact Details Here (Optional)

2. Are you wishing to implement centralised voicemail?

(Bandwidth considerations; to keep down Voicemails per site cost)

3. What telephones are to be implemented and how many of each type?

Eg. Digital, Analogue, IP Hard or Soft Phone, Please supply IPL all proposed IPO Configurations
Phone Type Qty Phone Type Qty Phone Type Qty Phone Type Qty

4. What type(s) of trunk(s) are currently installed/to be installed for your voice carriage?

Eg. ISDN Primary Rate, ISDN Basic Rate, Analogue PSTN Inc Carrier information
Expansion unit choice and provisioning of delay times

5. What kind of growth expansion is planned for your voice/data network?

Assists in determining which system will be required

Page 129 of 133

3, Data related brief questions For further information on most of the terms contained below please refer to the technical notes on page 5 1. What WAN technology is implemented across your network?

Eg. Frame Relay - Fully Meshed

(Needed for per channel bandwidth calculations) See Technical Notes for further information

2. Provisioned speed and type of data tails Eg. 256kbps - 128kbps CIR? - 1.5MB symmetrical See Technical Notes for further information

3. a. What Brand/Model/Specs of WAN routers are you running?

(Determine capabilities of router)

b. Who maintains these WAN routers?

(Info required should the supplier be required to assist)

4. What IOS (Operating System/ Firmware) are you running on these routers? Eg. 12.0.7T
(Determine capabilities of router)

5. Do you currently implement Fragmentation or MTU (Maximum Transmission Unit) restrictions on your router interfaces?
(bandwidth considerations)

6. Do you route SSL (Secure Sockets Layer) traffic across the WAN links?
(info required as fragmentation could be affected)

7. What current applications / traffic do you run over the WAN links?
(bandwidth considerations)

8. Do you have statistics available outlining usage on the WAN links and if so, can a copy be obtained for analysis? (check utilization for peak traffic / bursty traffic. Worst case scenario needs to be catered for)

(Specify contact name and number where statistics can be collected.)

Page 130 of 133

Do you have structured cabling in your location(s)?

(What type in each building? Cat3/Cat5 etc)

9. Is your LAN segmented into multiple VLANs?

(Info important if IP Phones to be used) See Technical Notes for further information

10. a. What L2/3 Switching infrastructure do you have in place?

Eg AVAYA Cajun Switch , Cisco Catalyst 1924

(Info required if IP Phones to be used)

a.

b. What version of software is currently on this infrastructure? b. 11. Is your LAN infrastructure capable of supporting 802.1p/q?
(Info required for prioritisation and queuing for IP Phones)

12. Do you perform and if required able to perform (L3 switching) within your LAN infrastructure?
(Info required if IP Phones, Phone Manager, voicemail etc are to be run across LAN)

13. Can a copy of the LAN/WAN network diagram be supplied?

(Copy of diagram in Microsoft Visio format preferred)

(Specify contact name and number where statistics can be collected.)

14. Are there Firewalls provisioned internally within the network if so what type/brand?

Eg. Cisco Pix / Packet filter?

(Info required if IP Phones, Phone Manager, voicemail etc are to be run across LAN) See Technical Notes for further information

15. Is there a Firewall in place and if so how big is the rule base?
(Info required to determine possible amount of network delay)

16. Do you wish to use Header Compression? (cRTP)

Bandwidth considerations) See Technical Notes for further information

Page 131 of 133

17. Do you wish to use silence suppression (VAD)?

(Bandwidth considerations) See Technical Notes for further information

18. Do you have any other high priority traffic requirements apart from Voice?
(Quality of Service (QoS) determination)

19. a. Are you running a Citrix or Terminal service environment?

(Phone Manager / Voicemail / Console / IMS)

b. If so how many concurrent sessions to each location?

20. a. Are there spare ports available on the routers(s)? eg: Serial - Ethernet b. Is any prioritization running on the routers(s)? eg: CBWFQ WFQ
(For example Lotus Notes data)

22. a. Are you now or in the future looking at using VPN technology to connect you branches? 23. a. Are you currently using xDSL technology to make up your network topology?

(ASDL/G.SHDSL Symmetrical High Bit Digital Subscriber Line /G.HDSL High Bit Digital Subscriber Line)

24. a. would you be interested in how IPL Communication and your reseller can help you with a complete network readiness assessment for VoIP?

Page 132 of 133

4, End user / Reseller confirmation sheet Date: ------------------------------------------Company: ------------------------------------------Name: ------------------------------------------I have taken the time to read this document and understand what is required of a network in order for Voice over Internet Protocol (VoIP) to function correctly. I understand that if I am running IP Hard Phones that VLAN and L3 routing configuration on my Ethernet network may be required in order for the phones to function correctly. I understand that if we wish to implement VoIP between sites (Locations) that the network must be able to support VoIP as per the specifications outlined in this document. CPE and carrier routing equipment/network may require additional software/hardware update and advanced programming on CPE carrier equipment in order for VoIP to function correctly. I understand that IPL Communication provide this document as a pure information source for resellers to gather and address customer needs and the customers current network configuration. It is the reseller/carriers responsibility to make sure that the network is configured for VoIP correctly.

SIGNED: ------------------------------------------Dated: -------------------------------------------

Page 133 of 133