Avaya SBCE Network Interface issues

 I was tasked with configuring a small Avaya SBC this week. I was sent a Dell 3240 system for this job. 

When I tried to power it on I was not able to get it to boot. I did some digging in the product manual and found a chart that showed what different LED sequences meant. I was getting three amber flashes and one white flash which meant that the CMOS battery was dead! Fortunately I keep a few batteries around and I was able to swap it out. The system powered on right away and I was able to load the SBC software.

You would think that would be it - off to the races, ready to go. Unfortunately there was one other problem. I was able to install the software and perform the CLI installation procedure without any hiccups. When I went to connect it to the lab network to perform the web config, though, I found that I was unable to reach the SBC and the SBC Was not able to reach my network. When I checked the interfaces it looked as if M1 was down! Not just that, but I also saw an A2 address that I thought was out of place. The additional network interface was my smoking gun - it was the built-in network interface. I went into the BIOS and disabled it, but that put me in worse shape - the M1 interface was now just missing entirely. I reloaded the software and everything worked out.

Here are some of the things I searched:

• Avaya SBC network interfaces wrong
• Avaya Dell 3240 bios
• M1 interface not responding
• Avaya SBC MAC Address wrong
• Avaya SBC M1 Down

SIP Standard

The VoIP world is dominated by SIP lately. SIP is a standard that is defined by a number of RFCs but searching through here for answers to questions is ridiculously difficult. I would like to use this post to answer any SIP questions that I come across in my daily travels. If you have a question that has not been answered feel free to drop it in the comments. I'll do my very best to find an answer for you!

Q: What is the maximum size of a SIP packet?
A: The maximum allowed size is equal to the maximum size of a UDP packet, or 65,507 bytes (65,535B - 20 B IP Header -8 B UDP Header). Some software may not accept packets of this size. Often software will limit the packet size to 4096B.

Q: What is a SIP User Agent (UA)?
A: A User Agent refers to a component in the SIP communication between two devices. There are two types of User Agents: Client and Server. A UA Client (UAC) sends a SIP request and a UA Server (UAS) sends a response. Most of the time a SIP server or endpoint will act as both a UAC and a UAS, depending on the circumstance. A call may terminate to a phone in which case the SIP server is the UAC and the phone is the UAS. The phone may then place the call on hold or conference another user, at which point the phone sends the request and becomes the UAC.

Q: What is a B2BUA?
A: A B2BUA (Back to Back User Agent) is a device that receives a request from a UAC and forwards that request out to another device, acting initially as the UAS and as the second leg as a UAC. A B2BUA will remain in the middle of the conversation so that the endpoints do not communicate directly for signaling purposes. It is still possible to have a B2BUA with direct media path for RTP packets.

Q: What is the maximum speed for faxing with SIP?
A: Contrary to what most people believe, there is no difference in the maximum speed of a fax machine on analog or PRI versus SIP. The SIP standard doesn't care - this is a function of the codec negotiation. But that doesn't answer the real question here. When I'm setting up a PBX I always suggest the customer limit their fax speed to 14,400bps. The PBX will see the 14,400 speed (or lower) and will use the T.38 codec for faxing. Most phone systems will only allow T.38 if the PBX will be holding up the RTP (i.e. no direct media path) as the system will switch to T.38 when it detects the fax tones being sent from the originating fax machine. Modern fax machines (also known as Super G3 fax machines) support speeds of up to 38,400bps, although the realized throughput is often lower. When using a Super G3 fax machine the codec will negotiate to G.711. Network reliability is incredibly important when using Super G3 speeds. These machines are incredibly intolerant to jitter and packet loss.

IP Office Registry Hacks

It has come to my attention that Avaya often hides functionality in a registry entry. I'm going to keep a list here. As I learn more I will add them. Feel free to comment any that you have tucked away under your cap!

Maximum UMS Users (166 by default):
Under HKEY_LOCAL_MACHINE/SYSTEM/CurentControlSet/Services/MSExchangeIS/ParametersSystem, add a new key MaxObjsPerMapiSesion. Under the new key, create a new DWORD Value objtMesageView, and set the value to three times the required users. For example, to support 500 users, set the value to 1500.

SIP Line Template:
In IP Office 9.1 the option for SIP Line Templates was included out of the box. In 7.0 and up the option is still there, but it's hidden. There is a two-part step to enable this:
Navigate to File --> Preferences on the IP Office Manager and select the Visual Preferences tab. Check the Enable Template Options box.
Under HKEY_CURRENT_USER/Software/Avaya/IP400/Manager and add a DWORD value TemplateProvisioning and set its value to 1. Reboot the server hosting the IP Office Manager.
You can now generate a SIP Trunk template

IP Office BCM CS1000 Integration with NRS

I recently had to network some BCMs, and IP Office 8.1, and a CS1000 together for four-digit dialing. I figure I will share some of my knowledge here. With the release of IP Office 9.0 a Session Manager is required which greatly simplifies the implementation, as long as you know how to route calls using Session Manager.

For the purpose of this article I'm going to assume that everyone knows the basics of how to build a SIP trunk on all three platforms. I will also assume that the appropriate licenses have been purchased and that the BCM is SIP capable.

Let's start with the CS1000. The NRS needs to be configured You will need to create endpoints for the BCMs and IP Offices, as well as any CS1000 locations that you have. The IP Office and BCM endpoints must be configured as static SIP endpoints.Routing entries need to be created for each endpoint to correspond with your dialing plan. It may seem obvious, but you need to build SIP trunks and routes from the CS1000. It is very important to note that the IP Office must be configured in Proxy Mode. The IP Office does not support Redirect Mode. Once you have finished with this you are done with the easy part.

The BCM configuration is also quite easy. Build your SIP trunks on the BCM. Configure your SIP domain and enable RTP keepalives. Calls will be routed on the Private network, so navigate to the Private tab under SIP Trunking. Ensure that your URI map matches the URI Map on your node:

Next you need to configure your routing table. For any BCM or CS1000 endpoint you need to enter the destination digits and direct it to the NRS IP. I also selected MCDN Protocol CSE. Ensure that the port number matches up with what the CS1000 is expecting. For each IP Office configure the destination digits per your dialing plan and use the IP address of the IP Office.

And now on to the fun piece. Configuring the IP Office is the most time consuming part of the whole setup. You need to configure three items: SIP Lines, Incoming Call Routes, and Short Codes.
For your SIP Lines you need a connection to each networked system. For simplicity I chose to use the same incoming call route, however the Line Group ID needs to be different for each site. In my example I used SIP Lines 17-20. All my Incoming Call Groups were 17, however I matched up the Line Group ID with the line number. Since these are IP trunks you can configure them however you like as long as they don't interfere with any other lines in the system. For the SIP line to the CS1000 use the Node IP address. For the BCM SIP Lines use the IP address of each individual BCM. Configure each SIP line with the maximum number of calls equal to the maximum number of SIP Line licenses in the system. This way each site is capable of having the maximum number of VoIP calls, as long as no other licenses are in use.
If you used the same incoming call route for each SIP trunk you only need to create a single incoming call route for IP calls. For the destination use a period (.) to have the call sent to whichever digits are being sent from the far end.
In order to make outgoing calls work you need to create short codes on the system to match the dialing plan. In my case we had four-digit dialing with each site having a unique first digit. This made it easy, I configured a short code for each first digit (i.e. 1XXX, 2XXX, 3XXX, etc.). Each short code was configured as Dial 3K1 using the appropriate line group for the far end site. The BCMs will not understand the standard dial string sent by the IP Office so you need to configure the phone context in the telephone number. In my example I showed the Private/CDP URI as cdp.udp so I needed the following Telephone Number in my short code:

.";phone-context=cdp.udp"

Once all of this is done just go ahead and commit your changes to the IP Office. It will probably require a reboot as you are changing IP information. Once everything comes up go ahead and make your test calls and give the customer a big smile on your way out the door, you're their hero.

As always feel free to comment if you have any questions. I'll always do my best to help!

The Signaling Server

A CS1000E system can have one of four types of signaling servers. There are two Signaling Servers that are available from a third party and there is the CP PM Signaling Server. In addition, there is support for the legacy ISP1100 Signaling Server.

The two COTS Signaling Servers that can be used are the IBM X306m Signaling Server and the HP DL320-G4 Signaling Server. Both of these servers can be configured using either Linux or the VxWorks software that the Nortel equipment uses. If the COTS signaling server is using Linux it adds the functionality of a tool called Enterprise Common Manager that allows for more advanced configuration options through a web interface than the default Nortel software allows through Element Manager.
The ISP1100 Signaling Server was used with previous releases and is supported for backwards compatibility. It is now discontinued and is not recommended, although it will function as a signaling server.

The CP PM Signaling Server uses the same hardware as the CP PM Call Server. There are a few small differences, however. The most noticeable difference is that the Signaling Server has a 40 GB Hard Disk Drive and no on-board Compact Flash. To enable the system to use the 40 GB Hard Disk Drive to load software it is necessary to set Switch 5 to position 2. Additionally, there is no security dongle on the Signaling Server.

The CP PM Signaling Server is connected either directly to the MGC or to a layer 2 switch using the ELAN and TLAN ports. Nortel recommends connecting them via a layer 2 switch. The ELAN port is used for address, data, and control signals between the various components of the CS1000E system. The TLAN port is used for telephony signaling traffic. The HSP port is not used on a signaling server. The indicator lights are the same as those on the CP PM Call Server.

The role of the signaling server is to provide SIP and H.323 signaling, IP phone signaling, and IP peer networking. The signaling server can use either VxWorks of Linux to perform these functions. The CP PM Signaling Server can only use VxWorks. A signaling server also provides the H.323 Gateway software to provide IP Peer Networking features between multiple MG1000Es and the CS1000E Call Server. In addition, it provides virtual trunk application and support for IP terminals. It can be configured with a survivability configuration and a load-sharing configuration. Each signaling server can support up to 5,000 IP users and a maximum of 1,800 SIP and H.323 trunks. Of these 1,800 trunks, a maximum of 1,200 H.323 trunks are available. This maximum can only be achieved if H.245 tunneling is enabled. If the server is running Personal Directory, Redial List, and Caller List, a maximum of 1,000 IP users are supported per Signaling Server.

A Signaling Server has a number of software applications that are installed to provide functionality. This includes the SIP/H.323 Gateway Signaling Software (for virtual trunks), IP Line Software (including the Terminal Proxy Server), a Network Routing Service (NRS) application, the Element Manager web server, the NRS Manager web server, and an application server that includes Personal Directory, Callers List, and Redial List.

Components of a SIP Network

As I mentioned previously, devices on a SIP network are called User Agents. A User Agent Client and a User Agent Server are both required for communication.

SIP defines three server elements: a Registrar, a Proxy Server, or a Redirect Server. A Registrar server accepts REGISTER requests and is typically co-located with a proxy server or a redirect server. It can offer location services, and registers SIP parties in a SIP domain. A Proxy Server functions as both a server and a client that makes and receives requests on behalf of other SIP clients. It supports requests locally or forwards them to other servers. It can interpret and re-write a SIP request message before forwarding it to another server or User Agent. A Redirect server will accept SIP requests, read the information and map the address in the request to the next hop. It will then return an appropriate message to the client. The client can then directly contact the appropriate next hop. It does not forward SIP requests to other servers and it does not accept calls. A SIP Redirect Server will only respond with 3xx series responses. It is important to note that these three types of SIP servers are logically, and not physically distinct.

In addition to the three server types and the User Agents that are present in a SIP Network, there are also Session Border Controllers (SBC) and gateways on the network. A Session Border Controller is inserted into the signaling path and handles the signaling and media being sent across the network. The SBC can also perform anti-tromboning functions. Tromboning occurs when two devices on the same subnet are both trying to connect through a third server when they should be allowed to connect directly. By directing the two devices to speak directly to each other the trunks can be opened up for use by other devices. An SBC can also implement transcoding when required, but this is not recommended, as was discussed previously. An SBC can restrict call flow or allow connections to exist where they would not have otherwise been able to exist (due to a firewall between the two end-points, or other security policies). It is also interesting to note that the Session Border Controller can enforce interception of network sessions. This is interesting because, without the SBC, there would be no way to intercept the flow of data between two SIP devices as can be required by various law enforcement agencies. This is because under normal circumstances SIP will try to have end-points communicate directly with each other. A Gateway simply acts as a connecting point between a SIP network and a dissimilar network, such as H.323 or PSTN. Any calls that are being sent out to the PSTN will have to go through a gateway.

Session Initiation Protocol

Session Initiation Protocol (SIP) is an alternative to H.323. It was created for the distribution of multimedia content. SIP supports a variety of architectures and protocols and is modeled after HTTP using plain text, which allows for easy packet inspection by administrators. It uses a Request-Response model (or INVITE model). It supports several types of proxy servers and operates on the Application layer of the OSI model. It leverages separate protocols that can be used without making any core protocol changes. It is totally independent of the voice path.

Every device on a SIP network is called a User Agent. A User Agent can serve two roles: If it is sending a request it is a User Agent Client (UAC) and if it is receiving a request it is a User Agent Server (UAS).

SIP supports two basic types of messages: Requests and Responses. SIP Requests and Responses are defined in the IETF RFC 3261. Every SIP message uses a start line that indicates if the message is a request or a response, as well as some other information including the version of SIP that is being used. I will start by going over requests and then discuss responses.

A request uses one of six methods. These methods are REGISTER, INVITE, ACK, CANCEL, BYE, and OPTIONS. REGISTER is quite obvious – it sends a message to a SIP Registration Server notifying it of its current IP address, as well as the URLs at which it wants to receive calls. INVITE is also fairly obvious; it indicates that a device wants to invite another user or service to participate in the session. ACK is an acknowledgement that the UAC has received a request, confirming that a message has been exchanged. CANCEL is used to terminate a pending request, but it does not terminate any already accepted calls. BYE end the call (this is what happens when you hang up). OPTIONS will query the capabilities of the UAS (the receiving end of a call) without setting up a call. There are additional SIP Extensions, defined by other RFCs, that include UPDATE (allowing the client to update the parameters of a session), INFO (carrying session-related control information during a session), PRACK (provides a Provisional Acknowledgement), and SUBSCRIB/NOTIFY (asking for notification from a remote node indicating that certain events have occurred). A request starts off with the method of the request, followed by the request URL and the SIP version.

A Response has a large number of possibilities. These possibilities are all covered in RFC 3261 as well. All responses have a three-digit code to identify what the response is. They are grouped into six categories, with each category being easily identified by the first digit in the code. A code beginning with a 1 is called a Provisional response, and indicates that a request has been received and is currently being processed, also called an informational response. A code that starts with 2 is a successful response, indicating that the UAS has received the request and understands it. A code beginning with 3 is a redirection response, indicating that further actions are required, usually by the sending User Agent, to complete the request. A 4 code indicates a failure. Often this is caused by bad syntax or an inability of the UAS to complete the request. A code starting with 5 is a server failure, indicating that the server was unable to process a request even though it looked like the request was valid. A code beginning with 6 indicates a global failure. Each of these six categories has a number of possible responses, as is indicated by the two remaining digits.

SIP uses two protocols to establish a conference call session: Session Announcement Protocol (SAP) and Session Description Protocol (SDP). SAP creates, modifies, and terminates sessions. It announces a conference session by periodically multicasting an announcement to a well-known multicast address port. SDP is a component of SAP, but can be used with RTSP, SIP, and as a standalone protocol. It is used to convey information to SIP entities and let them join and participate in a SIP session. SDP contains the purpose of the session, the name of the session, the media type pertaining to the session, formatted information for the session, and pertinent IP addresses and port numbers for the session.

VOIP Technologies

VoIP calls convert conversations into data packets which require a higher Quality of Service (QoS) and require security measures for Local Area Networks, Wide Area Networks, and Wireless Networks.
Signaling protocols and standards stipulate how networking equipment initiates and controls the flow of voice, video, and data communications. There are two major signaling protocol standards: H.323 and SIP.

H.323 is a suite of protocols that provides a foundation for audio, video, and data communications across IP-Based networks, including the Internet. H.323 is platform-, network-, and application-independent. It was created by the International Telecommunications Union (ITU), published in 1996. The current iteration of H.323 was published in 2006.

SIP stands for Session Initiation Protocol, and is a protocol that allows IP-Capable endpoints to create media sessions, such as telephone calls and video calls, with each other. SIP was developed by the Internet Engineering Task Force (IETF). SIP was originally started in 1996, and has evolved over the years into the current iteration. The initial SIP protocol was defined by RFC 2543, and the current version has been defined under RFC 3261. SIP is defined as a method of communication between multiple IP-based multimedia devices. SIP uses the Real-Time Transport Protocol (RTP) and the Session Description Protocol (SDP) to make communications possible between end-points. RTP transports the information, whether that is voice, video, or data. SDP is used to establish the session and session parameters. SIP is an Application-Layer protocol, and as such it allows for a variety of different applications, including voice, video, and gaming. SIP can work on IPv4 and IPv6 networks.

H.323
H.323 is comprised of six main components:
1. Media Gateway
2. H.323 Gateway
3. Call Servers
4. Gatekeepers
5. IP Terminals
6. IP Backbone Network

Starting at the top of the list, the Media Gateway converts one media stream into another. It can interact with call controllers, proxies, and soft switches using proprietary or standard protocols. It converts digital packets to analog and vice versa. It is the connecting point between the PSTN and the IP network.

The H.323 gateway transforms audio received from a telecommunications system into a format that the data network can use. It acts as a bridge to IP networks from voice networks and has built-in intelligence to select voice compression CODECs. It adjusts protocols and timing between two dissimilar computer systems, or voice-over-data networks. It performs the same functions as a media gateway.

A Call Server is responsible for helping to set up the calls on the data network. It receives call set-up request messages, determines the status of destination devices, and checks the authorization of users to originate or receive calls. The Call Server also creates and sends the necessary messages to process call requests.

A Gatekeeper provides call control, media access, and bandwidth management between endpoints. The Gatekeeper performs address translation, admissions control, and zone control. It will co-ordinate access to other servers and manage call routing. The Gatekeeper maps the destination telephone numbers to their destination end-point IP addresses. They can select the correct CODEC and translate between H.323 and other protocols. The Gatekeeper is the node that provides call control. In addition, the Gatekeeper can be used for a number of other functions, including dialing plans, call accounting, and many more. Gatekeepers can control the number of simultaneous calls, as well as the number of H.323 devices that can be supported on the network. The Gatekeeper is also responsible for managing all different zones.

IP Terminals and Clients are any end-point on the IP network. These can be hard phones or soft phones, as well as wireless devices. Basically, anything that brings voice and data communication to the end user.

The IP Backbone Network is the network on which the H.323 system is running. It must be IP-based. The number of devices that can be supported is partially defined by the bandwidth of this network. An IP network can be both wired and wireless. The IP network allows for dissimilar networks and systems to communicate and inter-connect.

H.323 is not as widely used as SIP. SIP offers greater flexibility than H.323 and is quickly eclipsing H.323 as the dominant protocol for VoIP traffic. SIP can inter-operate with H.323 networks through a SIP gateway. A SIP Gateway will sit at the edge of the SIP domain and translate what goes on inside the SIP domain into whatever the outside network needs (i.e. H.323 or PSTN, etc.). A SIP Gateway has two basic functions: translating the signaling stream and translating the media stream.