Author Message
GaryMoore2
Joined: Apr 22, 2014
Messages: 4
Offline
I see how I can make the connection with the user to user info class

UserToUserInfo userInfo = new UserToUserInfo(uui);
((LucentCall)call).connect((LucentTerminal)this.phoneTerminal, (LucentAddress)this.phoneAddress, numberToCall, true, userInfo);

But I am struggling in finding an example of how to code up the correct formatted bytes for the specific format of the UUI IE

I have tried the older ISDN format

byte[] uui = new byte[]{0x7e,0x0d,0,0x2a,21,39,37,30,32,32,32,31,32,33,34};

and the newer SIP format

byte[] uui = new byte[]{0x7e,0x12,0x14,0x0c,0,21,39,37,30,32,32,32,31,32,33,34,3,1,2,3};

neither of the 2 formats seem to work. I get unknown for the calling party id.

Anyone who has done so successfully and can help with the format would be greatly appreciated.
MartinFlynn
Joined: Nov 30, 2009
Messages: 1922
Online
I take it that:

1. You have two switches, connected by a H.323 or ISDN trunk.
2. When you make a normal call from the originating switch to the terminating switch, you DO see the calling number at the terminating switch.
3. You have SA8481 enabled on the originating switch
4. The originating switch is CM6.x or later.

I do see some errors in your uui arrays:

1. The Old format should be something like this:
0x2a,0x21,0x33,0x30,0x33,0x35,0x33,0x38,0x33,0x33,0x31,0x33

Unfortunately, the SA8481 documentation seems to have been cut and pasted from internal design docs and is based on ISDN Information Elements rather than the Userdata that the application has to provide. So dump the IE header data (0x7e,0x0d,0) as that is handled by AE Services.

2. The New format is OK in this regard - you can fill in the header data as whoever originally coded this on Communication Manager seems to also have been confused about IE headers & payloads.

3. All of the data in both formats should be Hex. For example - 39 decimal is an apostrophe while 0x39 is the character '9'. So, 39,37,30,32,32,32,31,32,33,34 should be 0x39,0x37,0x30,0x32,0x32,0x32,0x31,0x32,0x33,0x34

Martin
GaryMoore2
Joined: Apr 22, 2014
Messages: 4
Offline
Thank you for the reply Martin

I am not sure about #1 and #2 below. I'll pass that along to our Avaya systems administration team, and I have been working with them to trace the call to see what the calling party info looks like.

I do know they enabled the SA8481 in the CM and I believe our CM is on a version 6.3x, but will confirm this with them as well.

And thanks for the clarification on the format. Now it makes total sense. We need to pass the hex value of the ascii value of a character 9, not a byte with value of 39. The SA8481 was not super clear on this. Thank you for clarifying that.

Going to try your suggestions now!
GaryMoore2
Joined: Apr 22, 2014
Messages: 4
Offline
Many thanks again for your help Martin.

I was able to get teh UUI IE callign party data to pass through from Avaya AES JTAPI to the CM via the folloing format (and I used the UserToUserInfo class (Instead of the Q931UserToUserInfo class)

I wanted to post this here in case anyone else is looking for the format

The below format will present the calling party +1 970-222-1234

byte[] uui = new byte[]{0x7e,0x12,0x14,0x0c,0x00,0x21,0x39,0x37,0x30,0x32,0x32,0x32,0x31,0x32,0x33,0x34,0x00};
UserToUserInfo userInfo = new UserToUserInfo(uui);
((LucentCall)call).connect((LucentTerminal)this.phoneTerminal, (LucentAddress)this.phoneAddress, numberToCall, true, userInfo);
Go to:   
Mobile view