Hi,

we have SA8481 enabled on CM6.
Currently we try to modify the CLI send out for an outgoing call using DMCC.

The UUI is build like this - code is borrowed from an old thread here in the forums:

                        int extra = 2;

                        string cli = uui.Replace("FAKECLI", "");

                        ThreadPool.QueueUserWorkItem(o => SendMessage(sj.connection, MessageTypes.Info,cli));

                        char[] numbers = cli.ToCharArray();

                        int length = numbers.Length;

                        byte[] data = new byte[length + extra];

                        data[0] = 0x2a;

                        data[1] = 0x21;



                        for (int i = 0; i < length; i++)

                        {

                            data[i + 2] = Convert.ToByte(numbers[i]);

                        }



                        ThreadPool.QueueUserWorkItem(o => SendMessage(sj.connection, MessageTypes.Info, System.Text.Encoding.Default.GetString(data)));

                        p.UserData = new ThirdPartyCallController.UserData(data, length + extra);

                        sj.connection.Connection.serviceprovider.getThirdPartyCallController.MakeCall(p, null);

for ISDN we see the info coming to the Trunk but the presentation indicator is missing.
so not custom CLI is send to the called party.

for SIP we found the TSAPI FAQ entry stating the new format to be used. How can this be done using DMCC?
Unfortunately there is like zero documentation available on devconnect :(

thansk and best regards

The TSAPI FAQ for SIP SA8481 is "Why does Avaya Aura Communication Manager SA8481 no longer work with TSAPI when using a SIP trunk?". Using the example in the FAQ, the following DMCC message would have the same effect:

<MakeCall xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 

xmlns:xsd="http://www.w3.org/2001/XMLSchema" 

xmlns="http://www.ecma-international.org/standards/ecma-323/csta/ed3"> 

    <callingDevice typeOfNumber="other" 

mediaClass="notKnown">4501:CM120::0</callingDevice> 

    <calledDirectoryNumber typeOfNumber="other" 

mediaClass="notKnown">82240502:CM120::0</calledDirectoryNumber> 

    <userData> 

        <string>7e12100c00213937303232323132333403010203</string> 

    </userData> 

    <callCharacteristics> 

        <priorityCall>false</priorityCall> 

    </callCharacteristics> 

</MakeCall>

This can be achieved with something like the following C# code:

            byte presentation = 1;

            byte numberType = 0x21;

            byte pd = 0x10;

            String realCallingNumber = "40501:CM120::0";

            String calledNumber = "82240502:CM120::0";

            String newNumber = "9702221234";

            byte[] uui = { 0x01, 0x02, 0x03 };

            makeSA8481Call(presentation, numberType, pd, realCallingNumber, calledNumber, newNumber, uui);





        private void makeSA8481Call(byte presentation, byte numberType, 

                         byte pd, string realCallingNumber, string calledNumber, 

                         string newNumber, byte[] uui)

        {

            ThirdPartyCallController.MakeCallParameters prm = new ThirdPartyCallController.MakeCallParameters();

            ThirdPartyCallController.MakeCallPrivateData prv = new ThirdPartyCallController.MakeCallPrivateData();



            // Length of new number

            int numberLen = newNumber.Length;



            // Length of UUI data

            int uuiLen = uui.Length;



            // Size of buffer needed

            int byteLen = 7 + numberLen + uuiLen;



            // length of 'Information element'

            int ieLen = 5 + numberLen + uuiLen;



            // length of the number section

            int numSectionLen = 2 + numberLen;



            byte[] ba = new byte[byteLen];

            int count = 0;



            ba[count++] = 0x7E;

            ba[count++] = (byte)ieLen;

            ba[count++] = pd;

            ba[count++] = (byte)numSectionLen;

            ba[count++] = presentation;

            ba[count++] = numberType;



            // Put in the number

            for (int i = 0; i < numberLen; i++)

            {

                ba[count++] = (byte)newNumber[i];

            }



            // Put in the UUI

            ba[count++] = (byte)uuiLen;

            for (int i = 0; i < uuiLen; i++)

            {

                ba[count++] = uui[i];

            }



            // Make the call

            prm.UserData = new ThirdPartyCallController.UserData(ba, byteLen);

            prm.CalledDirectoryNumber = calledNumber;

            prm.CallingDevice = realCallingNumber;

            try

            {

                serviceProvider.getThirdPartyCallController.MakeCall(prm, null);

            }

            catch (Exception exc)

            {

                MessageBox.Show(exc.Message);

            }

        }

Thx for the Example...


got it now to send the proper UUI with the call

my XML now sends 7e12100c00213937303232323132333403010203 just as you example stated - for production it will of cause send a real number

BUT somehow the following 2 things happen:
via SIP trunks it is overwritten by the default number used for the SIP trunk
via ISDN trunk the phone called just displays "Private Number"

is there anything else that needs to be configured on AES/CM side for SA8481 we forgot?

on the old threads i saw a document beeing send around about SA8481 - does this contain additional steps which need to be made to get is working?
unfortunately this is pretty hard to find documentation on that special application :(

I do not know of any configuration directly related to SA8481, apart from enabling the feature via the change system-parameters special-applications table.

I take it that, of you make an outgoing call directly from a station, the far-end can see the number of the calling station. Correct?

I also take it that, when you make the same call but alter the calling number using SA8481, the far-end does not get the calling number. Correct?

Martin

well for ISDN it is like that:

in the mst trace for the trunk from CM we see that the presentation flag is completely missing when i pass the UUI part
also the Screening flag is completely missing as soon as i send the UUI part.
when i make a Manual call directly from the Station it is there and yes a number is shown on the called device
manually dialed:
<- CALLING PARTY NUMBER ................................. 3402301234
| type of number: national
| numbering plan: ISDN/telphny plan E.164/3 |cv ISDN/telphny pln
| presentation ind: presentation allowed
| screening: user provided not screened


via DMCC:
when i set presentation flag to 0x01 it Looks like this:
<- CALLING PARTY NUMBER ...............................xxxxxxxxxxx
| type of number: national
| numbering plan: ISDN/telphny plan E.164/3 |cv ISDN/telphny pln
| presentation ind: presentation restricted
| screening: user provided not screened

with presentation flag 0x00:
<- CALLING PARTY NUMBER ................................... 34012345
| type of number: national
| numbering plan: ISDN/telphny plan E.164/3 |cv ISDN/telphny pln

CM does not get any presentation or screening flag.


for SIP it Looks good - there i get the Alternate-CLI Header transmitted with the INVITE.

Question: do i Need to modify the from Header manually or is it basically the SIP Providers Task to work with the Alternate-CLI Header?

Hi Henrick,

I am not familiar with SIP signalling so I cannot help you with that. Though, I suspect the situation is similar to ISDN.

According to the documentation I have on the original ISDN version of SA8481:

7. Last octet - This octet is optional. If it is present, it will have the hexadecimal value ‘2a’. This is equivalent to the ascii character ‘*’. If this optional character is not present, no presentation indicator will be included when the calling party number IE is built. If this optional character is present, a presentation indicator will be included in the calling party number IE and it will be marked presentation restricted. If present in the UUI IE, this ‘*’ character will not be included in the address digits portion of the calling party number IE. ...

My reading of this is that if the application does not mark the calling number as restricted, Communication Manager will not include octet 3a in the Calling Party Number IE when sending the ISDN message over the trunk.

From the ETSI spec, I see a note:

... If octet 3a is omitted, and the network does not support subscription information for the calling party number information restrictions, the value "00 - presentation allowed" is assumed.

My reading of this is that if octet 3a is missing, the receiving switch can assume that the Calling Party Number presentation is allowed.

I also assume that the new, SIP version of SA8481, is handled similarly.

So, my conclusion is that, if the receiving switch is not displaying the Calling Party number, that is due to how it handles the IE without octet 3a (or, more probably, how it is configured to handle the IE).

It may be worth noting that, in my lab, I have two Communication Managers joined by an ISDN trunk and I do see the Calling Party number.

Martin

Note that the information in this PSN may be needed to get SA8481 operational on SIP trunks
https://download.avaya.com/css/public/documents/101035177