H323 trunks Part 1- Avaya Red to Blue with Gatekeeper non-RAS

From Old to New

When I got my first Voice certification a Nortel NNCS back in 2003  I found myself using Cisco documentation and the Cisco Press “Voice Over IP Fundamentals” to prepare to take the Nortel test on VOIP as Nortel did not have any decent organized documentation.    

Over the years I have noticed that Cisco has best documentation website not only for routers and data networking but also voice networking, This is a grudgingly slow admission for me as started in 1996 first learning Cisco routers, switches and the Nortel PBX at the same while working for Williams Field Services.The network field services team I worked had two divisions Voice and data and I was able to straddle both groups. Nortel was voice and Cisco was data and everything is great! All of us old voice guys hated it when Cisco started getting into Voice and we had no respect for Cisco Call Manager or the Idea of using a Cisco gateway. Unfortunately today you will find two camps the old guys who do Avaya Communication Manager who hate both Cisco and are forced to Call the Nortel PBX “Avaya Blue (which they also hate)”.

On the other hand is the young guy probably started in the Cisco Router and data switch world and then got a CCNA voice CCNP or the CCIE and now feels he knows everything about voice and thinks that Avaya and Nortel sucks. I am agnostic in all this I just like work on it all, You should never make any technology your religion.

The CS-1000 release 7.7 ends Avaya’s development of the CS-1000 and the support will end in 2020. But as of this date there are still quite a few of these systems around probably will still be around even after 2020. Likely it is the cost of replacement that keeps the old TDM PBX around, plus it is the 5 9;s. So I think there is still some worth to write about it.

H323 trunks between Avaya CS-1000 and Avaya Communication Manager (ACM)

In this Post I want to discuss H.323 and use the Cisco press book “Cisco Voice Gateway and Gatekeepers” (written by 3 CCIE’s Denise Donahue, David Mallory and Ken Salhoff) as past of my source material even though it is written around how it works with Cisco Call Manager. The rest of my resource material is the use of wire shark to analyze the call which was made on a real network and the data was captured using Network Instruments Observer tool. I have changed all of the IP addressing and Call info into bogus addresses and Call info. And in addition traces that I can do on CS-1000 signal servers

I will do an analysis of a H.323 call between an Avaya CS-1000 (formerly Nortel) and the Avaya CM (the original Avaya PBX) and use concepts mentioned in chapter 3 of “Cisco Voice Gateway and Gatekeepers”  to demonstrate how Avaya meets the H.323 specification. Of course the bigger question is why visit H.323 when SIP is the big thing now? I say we should know how it works because there is still a tremendous of Inter-networking between SIP and ISDN based networks. Besides I need to take a break from SIP and its many hours of looking wireshark traces to figure out one call.

The “Cisco Voice Gateway and Gatekeepers” authors state in chapter 3 that “The H323 standard is actually a suite of specifications that controls voice and video transmission over IP networks” 

So in my own words H323 is actually several sub protocols that make up the H.323 umbrella specification. I look at H.323 as ISDN signaling leaving the D Channel and continuing over a IP network.

If you are familiar with SIP you know that SIP is the signalling piece coupled with the Session Description Protocol providing information on Media negotiation and capabilities. Likewise we can say the H.225 is the SIP signalling method equal and H245 is the equal to SDP.

H225 has two parts:

  • H225 RAS Registration Admission and Status on UDP port 1719 for Gatekeeper controlled H.323 endpoints and trunks
  • H225 CS (Call signalling) between gateways and endpoints which typically use the ISDN Q.931 messages which uses TCP port 1720

H.245

  • “H.245 Protocol Controls traffic flow, performs DTMF relay, limits media transmission rates, negotiates capability, and controls opening and closing of channels for media streams. Uses TCP”

There are more protocols but I will not list here you can google or read the book I referenced here.

NRS is an H.323 Gatekeeper using the Direct Call Model

The Nortel (Avaya now) Network Routing Service (NRS) provides RAS signalling to CS-1000 networked PBX’s. The Nortel NRS can be both a H323 Gatekeeper and SIP Proxy server, in this example will see how it works as H.323 gatekeeper.

The NRS uses the Direct Call mode, which means the gateway (the CS-1000) will do the following:

  • H225 RAS in the Nortel PBX (via the signal server) will make a Admission Request (ARQ) to the NRS Gatekeeper. The query will use port 1719 UDP for the IP connection information of dialed number’s location
  • The NRS via 1719 UDP responds with a Admission Request Confirm (ACF) supplying the information IP connection information of the other gateway and authorizes the call to proceed
  • Upon receipt of the ACF from NRS Gatekeeper, Gateway to Gateway H225 Call Signalling and H,245 message begins which at this point the call is Direct signalling on port 1720 TCP and Gatekeeper is no longer involved until the Call disconnects.

Note: indirect mode the Gatekeeper is involved in Call Signalling and media negotiation

Setup information to analyze the ladder diagram in figure 1 take note of the following:

At this point you will scrolling up and down this page to view figure 1 at the bottom of this page, Observe in the left column is the CS-1000 Node IP address 192.131.12.10.

The node address

  • is virtual address but it is actually second address on the TLAN Ethernet interface of the signal server set as the Leader  in the NODE.
  • Node IP address on TLAN ethernet interface used for signaling and is not the TLAN IP address of the CS-1000.

So what is a Node in a CS-1000?

  • Basically a Node is collection of 1 to 2 signal servers and Voice Media Gateway Cards (commonly called the ITG card). Unlike Avaya Red that uses a C-LAN or CM Server IP address for signalling and a Medpro (Media Processor board) for RTP media, the CS-1000 ITG card can handle both signalling and Media, but it is preferred that a Signal server handle the signalling. In the Node arrangement there is a Leader and follower arrangement
  • the Node IP address can be taken over by a follower and when a election to become the Leader (typically this would be the second signal server)

The NRS database (gateway entries and configuration) and the Avaya CM

  • In the middle column is NRS server with an IP Address of 192.137.159.150.
  • in the very right column is the Avaya CM with an IP address of 192.195.77.110 (this CM is using processor Ethernet and not a CLAN, which a is like like setting up h323 trunks on a Cisco Call Manager). This address is used to setup a Signal group using port 1720 TCP on its side and then IP address 
  • The NRS has database gateway entry for the Avaya CM 192.195.77.110 setup as Non-RAS. The Non-RAS means that the Avaya CM does not actually register with NRS gatekeeper but is a static IP address entry that route entries of digits that can be dialed, along with defining what kind of call type (i.e. E.164 National, local) and a route cost (used if duplicate dial patterns are entered with same call type then a priority has to be established as to which gateway gets chosen first , 

What I setup to see the output displayed in Figure 1

To see the H225 RAS message on UDP port 1719

I logged into NRS and issued the gkCallTrace num 15132896444 (This is bogus number I made up do not call it) to replace the real number I called.

To see the H225 CS and H.245 messages on TCP port 1720

On CS-1000 signal server I issued the command H323CallTrace num 15132896444 (This is were the call will originate.

I also had access to Network Instruments Observer tool and I was able to find the call and then download and pull into wireshark to confirm and add some more detail to figure 1

What you see will see in

  1. H.255 RAS message that you see at beginning of the call is created when a phone on the CS-1000 dials 915132896444 which presents the call to the NARS/BARS table where the 9 is stripped and 15132896444 is a NPA with a route list index pointed to the CS-1000 IP H323 trunks that causes a query to the Gatekeeper ARQ and a Gatekeeper response ACF
  2. H.225 handles the call setup typically using ISDN q.931 signal messages and this signalling we now see between the Avaya Blue CS-1000 to the RED CM on TCP Port 1720.

Q.931 messages

  1. From the CS-1000 Q.931 Call Setup contains Q.931 Information Elements for Call-Caller display/and H225 Open Logical Channel Fast Start with source and destination IP addresses- port (1720) . Fast Start allows media transmission to begin quicker, instead of having to wait for an H.245 capabilities exchange. Fast Start is the default for Avaya Red. Blue and Cisco gateways and is useful when connecting to trunks and other connections that use in band audio signalling.
  2. Q.931 Call Proceeding from the Avaya Red PBX acknowledging Setup
  3. Q.931 Call Connect from the Avaya Red PBX contains the IP connection information for H.245 messages that will follow

    H.245 messages

H.245 Terminal Capabilities Exchange

  1. after the CS-1000 receives the connection info via Q.931 message from the ACM, the CS-1000 starts H.245 by sending it’s terminal capabilities set. In this case it is most of it was already taken care of the fast start negotiation during H.225 setup and Call Proceeding messages. If could look in wire shark trace of this message you see that the CS-1000 offered G.711 Ulaw, Alaw , at 10, 20 and 30 ms was offered and the DTMF type was null. looking down 3 lines you will see the terminal capabilities set from the ACM it offered back G.711 ulaw and G.729 at 10 ms.

H.245 Master/Slave Determination

Master/Slave Determination is used to resolve possible conflicts when either endpoint is  requesting the same feature or resource like controlling a conference call at the same time.

  1. In this trace the CS-1000 ends up becoming the Master and the ACM the slave.  Each side has a Master/Slave determination number value that they exchange through convoluted calculation the master and slave are determined.

H.245 Conference Indication

Since is call into an Avaya Conference bridge the conference capability and controlled from ACM side

Not shown at this point the RTP stream is up between the endpoints

Call Tear down

Finally we see the call tear down process after I pressed the release button on the 2050pc soft phone I called from.

H225 RAS

  1. The Disconnect request is sent to the NRS (DRQ)
  2. The NRS authorizes the Disconnect with Disconnect Confirm (DCF)

H.225/ Q.31 and H.245 close messages

I will talk about these in another post along H.245 tunneling in he Q.931 signalling

Figure 1  

h255-h245

Basic Call Control Comparison between Avaya and Cisco

Side by Side comparison of Avaya RED Communication Manager, Avaya Blue Call Server-1000 and Cisco Unified Call Manager

Facility Restriction Level or FRL

Communication Manager

  • Used in Class Of Restriction (COR) and Route Pattern

CS-1000

  • Used in Network Class Of Service (NCOS) and Route List Index

Both use FRL for the same purpose to apply access restrictions to phone and trunks

CM Example of restriction by FRL via COR on phone and FRL on route pattern

FRL_in_COR

CS-1000 example of restriction by FRL via NCOS on phone and FRL on route list index

CS-1000_FRL_NCOS

Route Pattern and Route List Index Only main function/features compared

CM

Route Pattern

  • Is a an ordered list of trunk groups were FRL can be applied, along with Digit manipulation.

CS-1000

Route List Index

  • Is also an ordered list of routes (trunk groups) FRL and digit manipulation is also applied.

UCM

  • Uses Route List Index like CS-1000
  • Does not use FRL (instead uses partitions contained in Call Search Spaces)
  • Digit manipulation can be applied
  • Route Patterns are numbers that can be dialed. (as opposed to a Route Pattern being an ordered list of trunks in Avaya Red)
  • Equal to dial pattern in Avaya Aura Session Manager

Basic phone set comparison

Avaya RED CM

  • Station or extension based
  • Does not use term Directory number
  • Assign call appearances (typically 3)

Avaya Blue CS-1000

  • Port based using a Terminal number
  • Assign Directory Number (s) to keys as per set type

UCM

  • MAC address based
  • Assign Directory Number (s) to keys as per set type

UCM Partitions and Call Search spaces

Instead of using FRL with COR or NCOS, Cisco Call Manager uses Partitions and Call Search Spaces

Partitions are created and assigned too:

  • Phones
  • directory numbers
  • call forward all (CFA)/call forward no answer (CFNA)/call forward busy (CFB) destinations,
  • gateways
  • and translation patterns 

All these can belong to specific partitions

Call Search Spaces (CSS)

  • Are an ordered list of route partitions and they determine which partitions the calling devices must search when they attempt to complete a call. In order to reach a certain destination, the called party’s partition must belong to the calling party’s CSS.

Example of Call Control using Partitions and Call Search Spaces

CSS_partitions

CS-1000 TARG/TGAR

TARG-TGAR

CM Partition Routing
Partition Group Number, Route Index and Partition-route-table

CM_partition_routing

CM routing by location

cm_location_routing

E.164 Call routing comparison 

  • CM uses Automatic Route Selection (ARS)
  • CS-1000 uses Network Automatic Route Selection (NARS) and Basic Automatic Route Selection (BARS) commonly called NARS-BARS
  • UCM uses Route Patterns (remember Cisco route patterns are dial patterns) with route filters and wildcards

CS-1000 CDP compared to CM and UCM

  • Coordinated Dial Plan or CDP
  • Distance Steering Code is a dial pattern that represents a phone-set(s)
  • For example 43 with a FLEN of 4 would represent 4300 to 4399 on another PBX
  • AAR or DCS is equal on CM
  • UCM is just another Route Pattern
  • All are dial patterns in Session Manager

I

An analysis of SIP Digest Authentication used in the SIP Registration Method

SIP authentication model based on the HTTP digest authentication described in the RFC 2617

This post is intended to be a neutral in its analysis of the vendors SIP registration process and the various vendors registration responses as analyzed in wire shark using the Conterpath free X lite soft phone. I have to admit that I am not very neutral about Counter path products I think there SIP soft phones are the best to benchmark other SIP phones.

I registered the X lite phone to a Cisco ISR gateway that is enabled as sip registrar, an Avaya Session Manager and for more comparisons a lab Cisco Call Manager and a version 5 Nortel NRS. The IP addresses used in these labs have been changed so that there is no possibility if revealing any proprietary information. You may also noticed paste overs on some of the screenshots, this also to avoid revealing any proprietary information.

 

You will see how Digest Access Authentication is used the SIP account password will be sent encrypted (normally as md5 hash of the password and some other values) and not sent in clear text.

Two types of SIP authentication that uses Digest authorization with MD5

  • Registration method

When a SIP User Agent sends Registration Request to SIP Registrar Server it will respond with a 401 Unauthorized with a challenge to provide credentials.

  • Proxy Authentication of outbound calls (which I will cover in another post)

When a SIP User Agent sends an Invite to a SIP server that will proxy the invite to a SIP Gateway, the SIP server will send back 407 Proxy Authentication Required

A RFC compliant SIP User-Agent will either: 1) Send ACK response to the server response to close the transaction. Or 2) Repeat the initial request and provide additional Authorization (for 401) or Proxy-Authorization (for 407) header in this message. This request must be sent with the same Call-ID and To, From headers as the original one and the CSeq (Command Seq) value must be incremented as seen in the wire shark trace below: SIP-reg-call-id-to-from-headers

 SIP Authentication Headers

The “WWW-Authenticate” header

  • Used by SIP Registrar Server this header is in the 401 unauthorized challenge for credentials from the User-Agent when the User Agent has made a request for registration

The “Proxy-Authenticate” header( will talk about this in another post)

  • Used typically when Proxy server is sending request to a gateway that has access to the PSTN network. But it is any call that goes over a SIP trunk to another PBX, Registrar Server that an endpoint exists.

SIP Server (User Agent Server) Challenge Strings

Here is a challenge string taken from a wire shark trace of a Xlite phone registering to a Cisco Gateway:   Cisco_gateway_reg_challenge   Server: Cisco-SIPGateway/IOS-15.2.4.M4 WWW-Authenticate: Digest realm=””,nonce=”1ADF55F80288CBA4″,algorithm=MD5,qop=”auth”

Here is the analysis of the string which is color coded to match color of text in string:

Challenge type used by the SIP Registrar server is: “WWW-Authenticate” Indicator of Authentication Scheme which is “Digest” Realm is the Protection Domain/or what I call the Dialing Domain ( in this string that I captured from a phone registered to a Cisco gateway no realm was configured) Nonce (Number Once) that can only be used one time. Every 401/407 challenge will contain a unique Nonce which means any data encrypted with it as only good for a single transaction.  Those encrypted credentials become completely worthless after a single use. Hash algorithm (which is MD5) qop Indicates what “quality of protection” the client has applied to the message. Typically it is always”auth” or “auth-int”

Challenge from Avaya Session Manager Server: AVAYA-SM-6.3.4.0.634014

Now the Avaya Session Manager string has a few more items in its Challenge string

WWW-Authenticate: Digest realm=”sip.test.com”,qop=”auth”,opaque=”1234567890abcedef”,nonce=”145f5ca9aac6f0b9f93433188d446ae0d9f91a6ff80“,algorithm=MD5,stale=true

 

As with the Cisco Gateway challenge string type is “WWW-Authenticate”  This time the realm is defined as it is required in Avaya Session Manager and the realm is “sip.test.com” A new option in the string is opaque=”1234567890abcedef” I find that neither the Cisco Gateway (ISR router) or Cisco Call Manager use the opaque option.

A second new option is “stale” notice in the Avaya SM capture that it is set to true. Typically if the “stale” element is in the string the value will be false. Hold the thought on this will explain why it is set to true in the next section “User Agent Client Response to challenge” opaque A string of data, specified by the server, which should be returned by the client unchanged.( This an extra mechanism that rogue phone would not know when it tried hack the call in progress). The opaque actually makes no sense to me as all Avaya Session Manager captures I have looked at it is always “1234567890abcedef” Stale is either True or false This used to for Server to track when client tries to re-use a Nonce which happens when endpoint Re-registers.

When I tested an old Nortel NRS version 5 it also has an opaque and stale WWW-Authenticate: Digest realm=”sip.lab.com”, nonce=”3f3b346de1b216b59b05daaec5b4b603″, opaque=”62bf8eaf6c0d967565423c4e47a39a8f”, stale=false, algorithm=MD5, qop=”auth”

User Agent Client Response to challenge

Xlite phone response to the challenge from the Cisco SIP gateway

Digest username=”4427″,realm=””,nonce=”63110EC902893319″,uri=”sip:192.168.15.101″,response=”c50963fa128e8db5069e262f176292fe”, cnonce=”a36f404a118bce981fe948ff26be22d4″,nc=00000001, qop=auth,algorithm=MD5 In second Registration request from the User Agent Client (Xlite SIP phone) is the response to the SIP server challenge the: the realm and Nonce are repeated back, then the following new values are added:

  • username is provided
  • The SIP URI is supplied
  • Response contains the encrypted password
  • CNONCE (Client NONCE) UAC supplied Nonce to effect final hash algorithm

Xlite phone response to Challenge from Avaya Session Manager User-Agent: X-Lite release 4.5.5  stamp 71236 Avaya SM xlite reg response   The

Xlite response to the Avaya SM challenge has additional component in the string: NC this is the NONCE count of requests sent by the client and supposedly must be present if qop is present. The nonce-count is used to avoid reply-attacks.

 

Now to my earlier observation looking at the wireshark snippets below “A second new option is “stale” notice in the Avaya SM capture that it is set to true. ”

WWW-Authenticate: Digest realm=”sip.test.com”,qop=”auth”,opaque=”1234567890abcedef”,nonce=”145f5ca9aac6f0b9f93433188d446ae0d9f91a6ff80″,algorithm=MD5,stale=true In this snippet from the wire shark trace we see the Xlite phone (line number 25 and source is 192.168.200.167) initiating a registration attempt with nonce that had been used in a previous registration attempt to Session Manager 192.168.148.164 (destination), notice it is also sending a  nc=00000002. This indicates that nonce is being more than one time. Now on line 26 Session Manager responds with a new challenge, notice the nonce value and the stale flag being “true” On line 27 we see that Xlite phone responds to the WWW-authenticate challenge by providing the credentials with the new nonce

registration-screenshot_wireshark_old_nonce.vsd

Wire Shark Summary of SIP registration

1Bindings