Warning: mkdir() [function.mkdir]: Permission denied in /home/otherguy/thatguygomer.com/gallery2/modules/core/classes/GalleryPlatform.class on line 582

Warning: mkdir() [function.mkdir]: Permission denied in /home/otherguy/thatguygomer.com/gallery2/modules/core/classes/GalleryPlatform.class on line 582

Warning: mkdir() [function.mkdir]: Permission denied in /home/otherguy/thatguygomer.com/gallery2/modules/core/classes/GalleryPlatform.class on line 582

Warning: mkdir() [function.mkdir]: Permission denied in /home/otherguy/thatguygomer.com/gallery2/modules/core/classes/GalleryPlatform.class on line 582

Cisco – Avaya

I had an interesting problem come up at work recently. I have a client who has 2 Cisco Call Manager 4.x clusters as well as a third Avaya solution. The Call Manager clusters are connected with the standard Cisco inter-cluster trunk. However, the Avaya was integrated into one Cluster as an H.323 gateway. The avaya is an S8500. So, the Call Manager cluster and the Avaya have been playing nicely all along with this H.323 gateway configuration, except that some of the features you expect out of a PBX don’t work. For example, even though call signaling works fantastic, the (cisco term) alerting name doesn’t work. This is an inherent limitation in the H.323 protocol stack. H.450.8 provides calling party information over H.323 trunks, but this is for the benefit of the called party. What my client wants is for the calling party to be alerted to whose phone is ringing (particularly useful to see when a call forwards or rolls to another extension). There is no such facility, however, in H.323. Luckily, the ITU foresaw the need for some of these supplementary services that fall outside the spec of H.323. To accommodate users with needs for more services, the ITU drafted some extensions (annexes) to H.323 to allow the tunnel of some SS7 protocols over H.323. Q.SIG (an ISDN signaling protocol) supports the services my client needs, so I chose to implement H.323 Annex M1 which defines Q.SIG tunneling over H.323. The call Cisco Call Manager offers the use of this standard as a configurable option. Allegedly, the Avaya S8500 does as well. So, my client’s Avaya guy has turned on the Q.SIG tunneling, and I in turn do the same. Well, now, we are worse off than before. Now, instead of the two PBXs exchanging the regular 4 or 5 digit extensions in call alerting, we are getting full 10 digit DID numbers instead. The expected behavior was to see the display of names in call alerting, including the “alerting name” displayed on the calling party’s phone corresponding to the phone ringing at the other end.

I can find tons of documentation on the web on integrating an Avaya S8500 and a Cisco Call Manager cluster using just straight H.323, and this was in fact working. I can also find tons of documentation about integrating the two using Q.SIG over an ISDN PRI. However, I can’t find any information about enabling Q.SIG over the H.323 trunk. I’m currently working with Cisco TAC to see if this configuration is even supported.

So, if anyone reading this has any experience with getting supplementary services working between these 2 PBXs, please let me know.

One Response to “Cisco – Avaya”

  1. gomer

    As it turns out, this is NOT a supported feature. Cisco TAC has informed me that you cannot get supplemental services working by enabling QSIG tunneling over H.323 between the Call Manager cluster and the Avaya.

    Too bad.

Leave a Reply

You must be logged in to post a comment.